From sadowski@cris.com Mon Jul 01 20:39:32 1996 
Received: from franklin.cris.com (franklin.cris.com [199.3.12.31]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id UAA00875 for <hfsig@tapr.org>; Mon, 1 Jul 1996 
20:39:30 -0500 (CDT) 
Received: from darius.cris.com (darius [199.3.12.32]) 
by franklin.cris.com (8.7.5/(96/06/11 2.45)) 
id VAA22882; Mon, 1 Jul 1996 21:38:55 -0400 (EDT) 
[1-800-745-2747 The Concentric Network] 
Errors-To: sadowski@cris.com 
Received: from LOCALNAME (cnc019099.concentric.net [206.173.35.99]) 
by darius.cris.com (8.7.3) 
id VAA11318; Mon, 1 Jul 1996 21:38:19 -0400 (EDT) 
Date: Mon, 1 Jul 1996 21:38:19 -0400 (EDT) 
Message-Id: <2.2.16.19960701214156.36d71956@pop3.cris.com> 
X-Sender: sadowski@pop3.cris.com (Unverified) 
X-Mailer: Windows Eudora Pro Version 2.2 (16) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
To: hfsig@tapr.org 
From: Paul Sadowski <sadowski@cris.com> 
Subject: About a Digital Comms Theory Book 


Request Please 


I seem to recall there was a mention of a book on Digital Comms that 
was due out "real soon"... somebody here I think was involved in it 
being written and maybe TAPR was going to publish / carry it??? I 
even think there was a draft table of contents mentioned... 


Anyone know what the story is ??? 


Mahalo and ALOHA 


From wd5ivd@tapr.org Mon Jul 01 21:15:01 1996 

Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id VAAQ2178 for 
hfsig@tapr.org; Mon, 1 Jul 1996 21:15:01 -0500 (CDT) 

From: Greg Jones <wd5ivd@tapr.org> 

Message-Id: <199607020215.VAA02178@tapr.org> 

Subject: Re: [HFSIG:1249] About a Digital Comms Theory Book 

To: hfsig@tapr.org 

Date: Mon, 1 Jul 1996 21:15:00 -0500 (CDT) 

In-Reply-To: <2.2.16.19960701214156 ..36d71956@pop3.cris.com> from "Paul Sadowski" 
at Jul 1, 96 08:54:14 pm 

X-Mailer: ELM [version 2.4 PL25] 

Content-Type: text 


There is a link to it on www.tapr.org on the bottom of the page with the 
details. 


Tom and myself are meeting the 4th to complete his edits. Then it is one 
last run through by the proof reader and then off to the press. We are 


shooting to go to the printers by the middle of July and then the date after 
that will be set by them on when we get them -- figure 4-5 weeks+ depending 
on backlog at their house. 


Still no price, since we don't have a quote yet from e printers. 


Cheers - Greg 


Request Please 

I seem to recall there was a mention of a book on Digital Comms that 
was due out "real soon"... somebody here I think was involved in it 
being written and maybe TAPR was going to publish / carry it??? I 
even think there was a draft table of contents mentioned... 


Anyone know what the story is ??? 


Mahalo and ALOHA 


VV VV VV VV VV VV VV WV 


From wd5ivd@tapr.org Tue Jul 02 00:08:42 1996 

Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id AAA14429; Tue, 

2 Jul 1996 00:08:40 -0500 (CDT) 

From: Greg Jones <wd5ivd@tapr.org> 

Message-Id: <199607020508.AAA14429@tapr.org> 

Subject: PC-DSP and PC-SIM for Windows - TAPR Group Purchase 

To: tapr-bb@tapr.org (TAPR-BB mailing), hfsig@tapr.org (HF SIG mailing), 
dsp-93@tapr.org (DSP-93 Build) 

Date: Tue, 2 Jul 1996 00:08:39 -0500 (CDT) 

Cc: psr@tapr.org (PSR) 

X-Mailer: ELM [version 2.4 PL25] 

Content-Type: text 


PC-DSP and PC-SIM for Windows - TAPR Group Purchase 


For the past several months, the subject of digital signal processing has 
been discussed on the TAPR DSP-93 and HFSIG e-mail lists. Software designed 
to facilitate the further learning and modeling of DSP entities has also 
been discussed (PC-DSP). Mention was made of a DSP course utilizing a text 
and a program called PC-DSP. The text is aptly named "Digital Signal 
Processing-A Laboratory Approach Using PC-DSP" by Oktay Alkin, PhD. 


Jim Kauten, KO4RQ, checked with PC Solutions, the developer of the software, 
and it was discovered that a Windows version is available. There are 
versions available for Win 3.1x, Win NT, and Win 95. 


After discussion with PC Solutions, they are willing to give a volume 
discount if there is enough interest. Jim announced the offer several weeks 
ago and approximately 30 people expressed an interest. Based on this 


interest TAPR will do a group purchase. 


The cost per unit for either the PC-SIM or PC-DSP (for Windows) package will 
be $220.00 US plus $6 shipping/handling (*). The normal price is $256 + s/h 
from PC Solutions. A savings of $30+ for all those involved in the group 
purchase. 


*21* orders must be placed with Dorothy at the TAPR office before the 
purchase will be made. These are orders (i.e. check, MO, or Visa/MC). This 
is not a call to generate a list that will be contacted at some future time. 
As with past group purchases, monies collected for the purchase will not be 
deposited until the order is placed. 


This information is available at: 
http: //www.tapr.org/tapr/html/dsp93.html 


Overview: 


The PC-DSP is an interactive, menu-driven software package used for: 
waveform synthesis using a variety of methods, basic signal operation, fast 
Fourier transforms, convolution and correlation, solution of difference 
equations, analysis and design of IIR and FIR filters, digital filter 
simulation and code generation, and power spectrum estimation using 
classical and modern techniques. Some key features of PC-DSP listed 
include: GNUPLOT support, code generation, macro compiler, dialog compiler, 
sound file support, data file formats, and compatibility with PC-SIM. 


PC-SIM is described as a continuous- and discrete-time simulator that is 
used for time-domain simulation of systems described by block diagrams. It 
was designed to be a flexible and open-ended tool to allow simulation of a 
broad range of systems encountered in communications, signal processing, and 
control theory. Some of the key features mentioned include: pre-defined 
components, code generation, sound file support, and compatibility with 
PC-DSP. 


Demo versions of both programs are available from the PC Solutions web site: 
http: //www.dspsolutions.com. 


Information regarding the software should be directed to Jim Kauten, MD, 
KO4RQ (kauten@mindspring.com) . 


Orders for software should be directed to the TAPR office tapr@tapr.org 


TAPR would like to thank Jim, KO4RQ, for his effort in organizing this 
purchase. 


TAPR 
8987-309 E. Tanque Verde Rd., #337 
Tucson, AZ 85749-9399 


Office: 817-383-0000 
Fax: 817-566-2544 
E-mail: TAPR@TAPR.ORG 


Office Hours: Tue - Fri, Yam - 12noon & 3pm - 5pm Central Time 


(x) Note: There will be no 10% membership discount on this purchase. 


July 2nd, 1996 


From chbrain@dircon.co.uk Tue Jul 02 01:06:45 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA19586 for <hfsig@tapr.org>; Tue, 2 Jul 
1996 01:06:42 -0500 (CDT) 
Received: by felix.dircon.co.uk id AA16754 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Tue, 2 Jul 1996 07:06:35 +0100 
Message-Id: <199607020606.AA16754@felix.dircon.co.uk> 
Received: from gw2-192.pool.dircon.co.uk(194.112.35.192) by amnesiac via smap 
(V1.3) 
id sma016727; Tue Jul 2 07:06:02 1996 
X-Sender: chbrain@popmail.dircon.co.uk 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Tue, 02 Jul 1996 06:58:27 +0100 
To: hfsig@tapr.org 
From: chbrain@dircon.co.uk (Charles Brain) 
Subject: Re: [HFSIG:1251] PC-DSP + PC-SIM 


Hello All, 
>simulation and code generation, and power spectrum estimation using 
>classical and modern techniques. Some key features of PC-DSP listed 


>include: GNUPLOT support, code generation, macro compiler, dialog compiler, 


I already have this software and I think it is very good. I am currently 
using PC-SIM to model a simple DS SS system. 


Does anyone know where to get a hold of GNUPLOT, I have searched 
the COMPUSERVE archives and all I can find is the manual ! 


Regards Charles G4GUO 


From frode@dxcern.cern.ch Tue Jul 02 02:22:22 1996 
Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by tapr.org 


(8.7.5/8.7.3/1.9) with ESMTP id CAA22728 for <hfsig@tapr.org>; Tue, 2 Jul 1996 
@2:22:20 -0500 (CDT) 
Received: from dxcern.cern.ch (frode@dxcern.cern.ch [137.138.28.189]) by 
dxmint.cern.ch 
with SMTP id JAA14910 for <hfsig@tapr.org>; Tue, 2 Jul 1996 09:21:48 +0200 
(MET DST) 
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA18506; Tue, 2 Jul 1996 09:21:48 +0200 
Date: Tue, 2 Jul 1996 09:21:47 +0200 (MET DST) 
From: Frode Weierud <frode@dxcern.cern.ch> 
To: hfsig@tapr.org 
Cc: hfsig@tapr.org 
Subject: Re: [HFSIG:1252] Re: PC-DSP + PC-SIM 
In-Reply-To: <199607020606.AA16754@felix.dircon.co.uk> 
Message-Id: <Pine.ULT.3.91.960702091539 .17640A-100000@dxcern.cern.ch> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Tue, 2 Jul 1996, Charles Brain wrote: 


> Does anyone know where to get a hold of GNUPLOT, I have searched 
> the COMPUSERVE archives and all I can find is the manual ! 

> 

> Regards Charles G4GUO 

> 

> 


Here are a few excerpts from the Gnuplot FAQ telling how to get hold of 
the FAQ and where to find the source code. The FAQ has answers to many 
other questions as well so it is advisable to get hold of that first. 


QO.1: Where do I get this document? 
This document is posted about once every two weeks to the 
newsgroups comp.graphics.apps.gnuplot, comp.answers and 
news.answers. Like many other FAQ's, its newest (plaintext) 
version is available via anonymous ftp from 
ftp://rtim.mit.edu/pub/usenet/news.answers/graphics/gnuplot-fa 
q. 


If you have access to the WWW, you can get the newest version 
of this document from 
http: //www.uni-karlsruhe.de/~ig25/gnuplot-faq/ 


Section 2: Setting it up 
Q2.1: What is the current version of gnuplot? 
The current version of gnuplot is 3.5, which is a bugfix 


release over 3.4. 


Version 3.6 is in beta status. Please note that this is still 
unstable, and may not compile correctly on your system. 


Q2.2: Where can I get gnuplot? 
All of the later addresses refer to ftp sites. Please note that 
it is preferable for you to use the symbolic name, rather than 
the IP address given in brackets, because that address is much 
more subject to change. 


The official distribution site for the gnuplot source is 
ftp.dartmouth.edu [129.170.16.4, soon to be 129.170.8.11], the 
file is called /pub/gnuplot/gnuplot3.5.tar.Z. Official mirrors 
of that distribution are (for Australia) ftp.monash.edu.au 
[130.194.11.18] and (for Europe) irisa.irisa.fr 
[131.254.254.2]. You can also get it from your friendly 
neighbourhood comp.sources.misc archive. 


MS-DOS and MS-Windows binaries are available from 


+ oak.oakland.edu (North America) [141.210.10.117] as 
/Simtel/msdos/plot/gpt35x.zip, 

+ garbo.uwasa.fi (Europe) [128.214.87.1] as /pc/plot/gpt35x*.zip 
and 

+ archie.au (Australia) [139.130.4.6] as 
micros/pc/oak/plot/gpt35x*.zip. 


The files are: gpt35doc.zip, gpt35exe.zip, gpt35src.zip and 
gpt35win.zip. 


There is a special MS-DOS version for 386 or better processors; 
it is available from the official gnuplot sites as DOS34.zip. 


OS/2 2.x binaries are at ftp-os2.nmsu.edu [128.123.35.151], in 
/0s2/2.x/unix/gnup1t35.zip. 


Amiga sources and binaries are available from ftp.wustl.edu 
[128.252.135.4] as /pub/aminet/util/gnu/gnuplot-3.5.lha; there 
are numerous mirrors of this distribution, for example 
ftp.uni-kl.de, oes.orst.edu or ftp.luth.se. 


The NeXTSTEP front end can be found at 
ftp://next-ftp.peak.org/pub/next/binaries/plotting/ as 
Gnuplot1.2_bin.tar.Z. 


A version for 0S-9/68K can be found at cabrales.cs.wisc.edu 
[128.105.36.20] as /pub/OSK/GRAPHICS/gnuplot32x.tar.Z; it 
includes both X-Windows and non - X-windows versions. 


There is a version for the Macintosh at 
ftp://ftp.ee.gatech.edu/pub/mac/gnuplot/ which includes 
binaries for 68000-based Macs with and without FPU and native 
support for PowerMacs. 


Versions for the Atari ST and TT, which include some GEM 
windowing support, are available from 


ftp://f£tp.uni-kl.de/pub/atari/graphics/, as gplt35st.zip and 
gplt35tt.zip. They work best under MiNT. 


Executable files, plus documentation in Japanese, exist for the 
X680x0 on 
ftp://ftp.csis.oita-u.ac.jp/pub/x68k/fj.binaries.x68000/vol2. 


People without ftp access can use an ftp-mail server; send a 
message saying 'help' to bitftp@pucc.bitnet (for BITNET only) 
or to ftpmail@ftp.dartmouth.edu. 


For a uuencoded copy of the the gnuplot sources (compressed tar 
file), send this as the body of a message to 
ftpmail@ftp.dartmouth. edu: 


open 

cd pub/gnuplot 

mode binary 

get gnuplot3.5.tar.Z 
quit 


If you have some problem, you might need to stick 


reply-to <your-email-address-here> 
before all the above. 


It is a good idea to look for a nearby ftp site when 
downloading things. You can use archie for this. See if an 
archie client is installed at your system (by simply typing 
archie at the command prompt), or send mail to archie@sura.net 
with the word 'help' in both the subject line and the body of 
the mail. However, be aware that the version you find at a near 
ftp site may well be out of date; check the last modification 
date and the number of bytes against the newest release at one 
of the official servers. 


You can obtain a beta release of gnuplot 3.6 from 
ftp://cmpc1.phys.soton.ac.uk/pub/. 


73's Frode, F/LA2RL 


Frode Weierud Phone : 41 22 7674794 
CERN, SL, CH-1211 Geneva 23, Fax : 41 22 7679185 
Switzerland E-mail : Frode.Weierud@cern.ch 


From zs6awk@global.co.za Tue Jul 02 15:26:06 1996 

Received: from 1in01.global.co.za (1in01.global.co.za [196.3.164.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id PAA23671 for <hfsig@tapr.org>; Tue, 2 Jul 1996 
15:26:03 -0500 (CDT) 

Received: from anx_pt_9.global.co.za (anx_pt_9.global.co.za [196.3.165.209]) by 


lin01.global.co.za (8.7.3/8.7.3) with SMTP id WAA24050 for <hfsig@tapr.org>; Tue, 
2 Jul 1996 22:24:43 -0200 (GMT) 

Message-Id: <199607030024.WAA24050@1in01.global.co.za> 
X-Sender: zs6awk@mail.global.co.za 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Tue, 02 Jul 1996 22:26:23 +0200 

To: hfsig@tapr.org 

From: zs6éawk@global.co.za (Danie Brynard) 

Subject: PSK Question. . 


I am sorry if my questions are out of sync with the ongoing PSK/QPSK 
discussions but could somebody just answer the following perhaps for me again: 


1) A Costasloop for BPSK demodulation will typically lock 0 or 180 degrees 
out of phase with the incoming carrier. Can it also lock 90 or 270 degrees 
out of phase and what would typically be the reasons for this ? 


2) What is the minimum signal to noise required for the following BPSK 
demodulator techniques: 


- squaring loop PLL type 
- PSK Costas Loop 
- or perhaps what is the minimum SNR for a PLL to maintain phase lock ? 


Any references would of course be welcomed ie page number in a textbook. I 
have implemented two RTTY modems for the DSP56002EVM. The one is based on a 
DPLL for fsk demod. I was wondering what the minimum theoretical SNR is that 
would keep the DPLLL in lock...from there my thoughts & questions. 


Regards, Danie zs6awk 
zs6éawk@global.co.za 


From mcdermot@rdxsunhost.aud.alcatel.com Tue Jul 02 16:30:51 1996 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id QAA26800 for <hfsig@tapr.org>; Tue, 2 Jul 
1996 16:30:49 -0500 (CDT) 
Received: from rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM by aud.alcatel.com (4.1/ 
SMI-4.1) 
id AA11488; Tue, 2 Jul 96 16:30:48 CDT 
Received: from eagle.aud.alcatel.com by rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM 
(4.1/SMI-4.1) 
id AA13952; Tue, 2 Jul 96 16:30:47 CDT 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ7929; Tue, 2 Jul 96 16:30:46 CDT 
Date: Tue, 2 Jul 96 16:30:46 CDT 
From: mcdexrmot@rdxsunhost.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9607022130.AA07929@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1254] PSK Question. . 


I am sorry if my questions are out of sync with the ongoing PSK/QPSK 
discussions but could somebody just answer the following perhaps for me again: 


1) A Costasloop for BPSK demodulation will typically lock © or 180 degrees 
out of phase with the incoming carrier. Can it also lock 90 or 270 degrees 
out of phase and what would typically be the reasons for this ? 


VV VV VV 


Danie: there is in fact zero error voltage at the wrong lock 
points (90, 270). However, the loop-sense is backwards at these two 
points. Thus the loop will not stay locked at the wrong points as 
drift, noise, etc. will cause the loop to 'kick-out' of those two 
points. The feedback loop is only stable at the © and 180 degree 
points. 


2) What is the minimum signal to noise required for the following BPSK 
demodulator techniques: 


- squaring loop PLL type 
- PSK Costas Loop 
- or perhaps what is the minimum SNR for a PLL to maintain phase lock ? 


VVVVV VV 


This is a difficult question to answer analytically, and I 
think empirical results are more trustworthy. I think that the answer 
is implementation dependent. No good references to give you right now. 


- Tom 


Tom McDermott 
mcdermot@aud.alcatel.com 


From karn@qualcomm.com Tue Jul 02 18:02:43 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id SAA03310 for <hfsig@tapr.org>; Tue, 2 Jul 1996 
18:02:41 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
QAA13658; Tue, 2 Jul 1996 16:02:09 -0700 (PDT) 

Date: Tue, 2 Jul 1996 16:02:09 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607022302.QAA13658@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <9607022130.AA07929@eagle.aud.alcatel.com> 
(mcdermot@rdxsunhost.aud.alcatel.com) 

Subject: Re: [HFSIG:1255] Re: PSK Question.. 


2) What is the minimum signal to noise required for the following BPSK 
demodulator techniques: 


- squaring loop PLL type 
- PSK Costas Loop 


VV VV WV 


> - or perhaps what is the minimum SNR for a PLL to maintain phase lock ? 


The squaring loop and Costas loop behave identically with appropriate 
choice of filters. There's no theoretical performance advantage of one 
over the other. The main differences are practical, such as the lower 
frequencies inherent in the Costas loop approach (which makes it more 
easily implemented with DSP). 


When designed for BPSK, both loops behave about 6 dB worse than a CW 
PLL (i.e., an ordinary PLL without any means for removing PSK 
modulation). When designed for QPSK, they're both about 12 dB 

worse. This is for relatively strong signals that are above a certain 
threshold. Even worse, there is an additional "squaring loss" that 
depends on the signal-to-noise ratio in the loop that increases the 
loss at low SNR. This behavior is inherent in a loop that removes 
modulation -- it's not the fault of either the Costas or squaring loop 
design. 


Phil 


From wd5ivd@tapr.org Tue Jul 02 23:00:20 1996 

Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id XAA15843; Tue, 

2 Jul 1996 23:00:18 -0500 (CDT) 

From: Greg Jones <wd5ivd@tapr.org> 

Message-Id: <199607030400. XAA15843@tapr.org> 

Subject: Update on PC-DSP and PC-SIM Group Purchase 

To: dsp-93@tapr.org (DSP-93 Build), hfsig@tapr.org (HF SIG mailing), 
tapr-bb@tapr.org (TAPR-BB mailing), psr@tapr.org (PSR) 

Date: Tue, 2 Jul 1996 23:00:17 -0500 (CDT) 

X-Mailer: ELM [version 2.4 PL25] 

Content-Type: text 


Update on TAPR Group Purchase of the PC-DSP and PC-SIM software. It was 
unclear in the first posting that this was indeed a software bundle. Sorry 
for any problems this might have caused. 


We received 5 orders just today at the TAPR office -- so get those orders 
rolling! 


PC-DSP and PC-SIM for Windows (bundle) - TAPR Group Purchase 


For the past several months, the subject of digital signal processing has 
been discussed on the TAPR DSP-93 and HFSIG e-mail lists. Software designed 
to facilitate the further learning and modeling of DSP entities has also 
been discussed (PC-DSP). Mention was made of a DSP course utilizing a text 
and a program called PC-DSP. The text is aptly named "Digital Signal 
Processing-A Laboratory Approach Using PC-DSP" by Oktay Alkin, PhD. 


Jim Kauten, KO4RQ, checked with PC Solutions, the developer of the software, 
and it was discovered that a Windows version is available. There are 
versions available for Win 3.1x, Win NT, and Win 95. 


After discussion with PC Solutions, they are willing to give a volume 
discount if there is enough interest. Jim announced the offer several weeks 
ago and approximately 30 people expressed an interest. Based on this 
interest TAPR will do a group purchase. 


The cost for the software bundle (PC-SIM and PC-DSP (for Windows)) will be 
$220.00 US plus $6 shipping/handling (*). The normal price is $256 with s/h 
from PC Solutions. A savings of $30 for all those involved in the group 
purchase. 


*21* orders must be placed with Dorothy at the TAPR office before the 
purchase will be made. These are orders (i.e. check, MO, or Visa/MC). This 
is not a call to generate a list that will be contacted at some future time. 
As with past group purchases, monies collected for the purchase will not be 
deposited until the order is placed. 


This information is available at: 
http: //www.tapr.org/tapr/html/dsp93.html 


Overview: 


The PC-DSP is an interactive, menu-driven software package used for: 
waveform synthesis using a variety of methods, basic signal operation, fast 
Fourier transforms, convolution and correlation, solution of difference 
equations, analysis and design of IIR and FIR filters, digital filter 
simulation and code generation, and power spectrum estimation using 
classical and modern techniques. Some key features of PC-DSP listed 
include: GNUPLOT support, code generation, macro compiler, dialog compiler, 
sound file support, data file formats, and compatibility with PC-SIM. 


PC-SIM is described as a continuous- and discrete-time simulator that is 
used for time-domain simulation of systems described by block diagrams. It 
was designed to be a flexible and open-ended tool to allow simulation of a 
broad range of systems encountered in communications, signal processing, and 
control theory. Some of the key features mentioned include: pre-defined 
components, code generation, sound file support, and compatibility with 
PC-DSP. 


Demo versions of both programs are available from the PC Solutions web site: 
http: //www.dspsolutions.com. 


Information regarding the software should be directed to Jim Kauten, MD, 
KO4RQ (kauten@mindspring.com). 


Orders for software should be directed to the TAPR office tapr@tapr.org 


TAPR would like to thank Jim, KO4RQ, for his effort in organizing this 
purchase. 


TAPR 
8987-309 E. Tanque Verde Rd., #337 
Tucson, AZ 85749-9399 


Office: 817-383-0000 
Fax: 817-566-2544 
E-mail: TAPR@TAPR.ORG 


Office Hours: Tue - Fri, Yam - 12noon & 3pm - 5pm Central Time 


(x) Note: There will be no 10% membership discount on this purchase. 


July 2nd, 1996 


From wd5ivd@tapr.org Tue Jul 02 23:21:02 1996 

Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id XAA17015; Tue, 
2 Jul 1996 23:21:00 -0500 (CDT) 

From: Greg Jones <wd5ivd@tapr.org> 

Message-Id: <199607030421.XAA17015@tapr.org> 

Subject: One more time 

To: dsp-93@tapr.org (DSP-93 Build), hfsig@tapr.org (HF SIG mailing) 

Date: Tue, 2 Jul 1996 23:21:00 -0500 (CDT) 

X-Mailer: ELM [version 2.4 PL25] 

Content-Type: text 


Just in case the last update was a little unclear -- this should be real 
clear for everyone :-) 


Greg 


The cost of the PC-SIM and PC-DSP for Windows package (includes both 
programs) will be $220.00 US (*). Shipping and handling will be an 
additional $6 for US deliveries. The standard non-discounted price for the 
package is $256.00, inclusive of s/h, from PC Solutions. The TAPR group 
purchase plan nets a savings of $30.00 for each person involved in the 
purchase of the software package. 


*21* orders must be placed with Dorothy at the TAPR office before the 
purchase will be made. These are orders (i.e. check, MO, or Visa/MC). This 
is not a call to generate a list that will be contacted at some future time. 
As with past group purchases, monies collected for the purchase will not be 
deposited until the order is placed. 


This information is available at: 
http: //www.tapr.org/tapr/html/dsp93.html 


From zs6awk@global.co.za Wed Jul 03 14:58:57 1996 

Received: from linO1.global.co.za (linO01.global.co.za [196.3.164.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id OAA04568 for <hfsig@tapr.org>; Wed, 3 Jul 1996 
14:58:34 -0500 (CDT) 

Received: from anx_pt_6.global.co.za (anx_pt_6.global.co.za [196.3.165.206]) by 
lin01.global.co.za (8.7.3/8.7.3) with SMTP id VAA05539 for <hfsig@tapr.org>; Wed, 
3 Jul 1996 21:57:06 -0200 (GMT) 

Message-Id: <199607032357.VAA05539@1in01.global.co.za> 

X-Sender: zs6awk@mail.global.co.za 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Wed, 03 Jul 1996 21:58:47 +0200 

To: hfsig@tapr.org 

From: zs6awk@global.co.za (Danie Brynard) 

Subject: Re: [HFSIG:1256] Re: PSK Question.. 


Thanks for the answers I received on my PSK question. However one thing I am 
still not certain about: what is the minimum SNR required for a theoretical 
ideal PLL to lock onto a CW signal ? (ok there is normally a pull-in range 
and a hold-in range involved which might require different minimum SNR's) 


Somebody wispered 6dB into my ear :-) 


73 danie 
zs6awk@global.co.za 


From togo@of.net Thu Jul 04 17:10:02 1996 

Received: from aloha.com (root@mango.aloha.com [206.43.235.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id RAA15165 for <hfsig@tapr.org>; Thu, 4 Jul 1996 
17:10:00 -0500 (CDT) 

Received: from maui117.maui.net (maui117.maui.net [206.154.205.167]) by aloha.com 
(8.7.4/8.6.5) with SMTP id MAAO2376 for <hfsig@tapr.org>; Thu, 4 Jul 1996 12:09:56 
-1000 (HST) 

Message-Id: <199607042209 .MAA02376@aloha. com> 

Comments: Authenticated sender is <togo@mail.aloha.com> 

From: "Tony Godshall" <togo@of.net> 

To: hfsig@tapr.org 

Date: Thu, 4 Jul 1996 12:22:56 +0000 

Subject: Re: [HFSIG:1249] About a Digital Comms Theory Book 

Reply-to: togo@of.net 

Priority: normal 

X-mailer: Pegasus Mail for Windows (v2.23) 


[Paul Sadowski "[HFSIG:1249] About a Digital Comms " 1 Jul 96] 
> Mahalo and ALOHA 


Aloha! Are you in or from Hawaii? It would be good to get in touch 
with others with digital HF interests. I'm in Pukalani Maui. 


73 de WH6ZD 


Best regards. 
Anthony Godshall 


Paradigm Shifting and Testing 
Digital Models and Transformations 
Project Engineer, Educator, Programmer 


From john-f£@bachrach.Com Fri Jul 05 08:49:30 1996 
Received: from sparky.midwest.net (root@sparky.midwest.net [204.248.40.3]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id IAA27707 for <hfsig@tapr.org>; Fri, 5 Jul 
1996 08:49:28 -0500 (CDT) 
Received: (from bachrach@localhost) by sparky.midwest.net (8.6.12/8.6.9) with UUCP 
id IAA29614 for hfsig@tapr.org; Fri, 5 Jul 1996 08:18:10 -0500 
Received: from Connect2 Message Router by bachrach.bachrach.Com 
via Connect2-UUCP v1.00; Fri, 5 Jul 96 08:27:54 -@500 
Message-Id: <D75DD83101000000@bachrach.Com> 
Date: Fri, 5 Jul 96 08:27:42 -0500 
Sender: John Fischer <john-f@bachrach.Com> 
From: John Fischer <john-f@bachrach.Com> 
Return-Receipt-To: John Fischer <john-f@bachrach.Com> 
Organization: bachrach Clothing, Inc. 
To: hfsig@tapr.org 
Subject: subscribe 
X-Mailer: Connect2-UUCP v1.00 


From togo@of.net Fri Jul 05 14:33:36 1996 

Received: from aloha.com (root@mango.aloha.com [206.43.235.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id 0AA17540 for <hfsig@tapr.org>; Fri, 5 Jul 1996 
14:33:31 -0500 (CDT) 

Received: from maui94.maui.net (maui94.maui.net [206.154.205.144]) by aloha.com 
(8.7.4/8.6.5) with SMTP id JAA16389 for <hfsig@tapr.org>; Fri, 5 Jul 1996 09:33:24 
-1000 (HST) 

Message-Id: <199607051933.JAA16389@aloha. com> 

Comments: Authenticated sender is <togo@mail.aloha.com> 

From: "Anthony Godshall" <togo@of.net> 

To: hfsig@tapr.org 

Date: Fri, 5 Jul 1996 09:44:40 +0000 

Subject: Re: TACO-2 low overhead protocol (was Re: Sound Card Interface) 
Reply-to: togo@of.net 

Priority: normal 

X-mailer: Pegasus Mail for Windows (v2.23) 


[Sadowski,P, 7 Mar 96] 


US DoD went through extreme pain and agony over the overhead 

of the new protocols over low bandwidth channels. ... they came up with 
a low overhead protocol... with FEC option... called TACO 2 

(tactical comm protocol). I suggest the SIG look into this 

protocol.... DoD has been seeking IEEE or ISO standard for this 


VV VV WV 


> protocol. Its tailor made for low BW RF links... 


In case anyone else wants to follow up on the above, I found specs in 
Zipped Wordperfect format at 
ftp://ftp.itsi.disa.mil/pub/library/nitfs_docs/taco2.zip 
which were referenced from web page 
http: //www.tasc.com/NITFS/NITFS_docs.html 


Best regards. 
Anthony Godshall 


Paradigm Shifting and Testing 
Digital Models and Transformations 
Project Engineer, Educator, Programmer 


From gzluhuih@public1. guangzhou.gd.cn Fri Jul 05 20:41:59 1996 

Received: from public1.guangzhou.gd.cn (public1.guangzhou.gd.cn [202.96.128.111]) 
by tapr.org (8.7.5/8.7.3/1.9) with SMTP id UAAQO771 for <hfsig@tapr.org>; Fri, 5 
Jul 1996 20:41:50 -0500 (CDT) 

Received: from default.pc (ppp54.guangzhou.gd.cn [202.96.129.54]) by 
public1.guangzhou.gd.cn (8.6.11/8.6.11) with SMTP id JAA10801 for 
<hfsig@tapr.org>; Sat, 6 Jul 1996 09:43:51 +0900 

Message-ID: <31DDB504.651C@public1. guangzhou.gd.cn> 

Date: Sat, 06 Jul 1996 09:36:20 +0900 

From: Lu Hui-Hua <gzluhuih@publici1. guangzhou.gd.cn> 

Reply-To: bd7ix@amsat.org 

X-Mailer: Mozilla 3.0b3Gold (Win95; I) 

MIME-Version: 1.0 

To: hfsig@tapr.org 

Subject: HELP, (TNC) 

References: <199607051933 .JAA16389@aloha. com> 

Content-Type: text/plain; charset=us-ascii 

Content-Transfer-Encoding: 7bit 


hello everybody, here is BD7IX(Lu Hui-Hua) from P.R.CHINA. 
somedays ago, i send a mail at here , said want to know how 
to made a modem(tnc) myself, my plan is use TCM3105 or 
AM7910(7911) chip to do it, but unfortunate, the chip is 

not produce. soi think maybe motorola's MC145442 OR MC145443 
can replace it. but mc145442(3) only can use 300 baud 

(CCITT V.21 OR BELL 103). 

who can tell me the alternative else? 

and if i use MC145442(3), who can give the circuit design about it? 
please tell me via e-mail bd7ix@amsat.org 

thanks 


Lu Hui-Huaxbd7ixx 


From togo@of.net Fri Jul 05 20:52:31 1996 

Received: from aloha.com (root@mango.aloha.com [206.43.235.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id UAA01270 for <hfsig@tapr.org>; Fri, 5 Jul 1996 
20:52:29 -0500 (CDT) 


Received: from maui137.maui.net (maui137.maui.net [206.154.205.187]) by aloha.com 
(8.7.4/8.6.5) with SMTP id PAA22253 for <hfsig@tapr.org>; Fri, 5 Jul 1996 15:52:24 
-1000 (HST) 

Message-Id: <199607060152.PAA22253@aloha.com> 

Comments: Authenticated sender is <togo@mail.aloha.com> 

From: "Anthony Godshall" <togo@of.net> 

To: hfsig@tapr.org 

Date: Fri, 5 Jul 1996 16:03:23 +0000 

Subject: FECC Chipsets (and an apology) 

Reply-to: togo@of.net 

Priority: normal 

X-mailer: Pegasus Mail for Windows (v2.23) 


The apology is at the bottom. The question is, will anyone take me 
seriously now? 


Anyway, I found Phil's discussion of FEC very enlightening (Realaudio 
and slides at http://www.tapr.org/tapr/html/taprstlouis.htmldé#karn) - 
it is well worth listenging carefully and rewinding some to get 
though the background noise. 


What I am wondering, with CD's so popular, is it possible to adapt 

CD-ROM chipsets to radio? I searched the web and the newsgroups, and 

the only ECC chip I could find mentioned was a single mention of a 

L64715 BCH error correction chip from LSI Logic, and no comp.compression FAQ 
(ftp: //rtfim.mit.edu/pub/usenet/news.answers/compression-faq/) 


The apology... I said... 


> Aloha! Are you in or from Hawaii? It would be good to get in touch 
> with others with digital HF interests. I'm in Pukalani Maui. 


Oops. Color me newbie. Damn, I could have sworn I addressed that 
properly. Anyway, I am sorry, as I wipe the egg off my face, for 
wasting the bandwidth in such a juvenile way, and again now. 


Best regards. 
Anthony Godshall 


Paradigm Shifting and Testing 
Digital Models and Transformations 
Project Engineer, Educator, Programmer 


From k6sti@n2.net Sat Jul 06 12:02:46 1996 

Received: from ravel.n2.net (ravel.n2.net [204.250.22.20]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id MAA12971 for <hfsig@tapr.org>; Sat, 6 Jul 1996 
12:02:44 -0500 (CDT) 

Received: from ppp166.n2.net (ppp166.n2.net [204.250.22.166]) by ravel.n2.net 
(8.6.12/8.6.12) with SMTP id KAA25622; Sat, 6 Jul 1996 10:04:19 -0700 

Date: Sat, 6 Jul 1996 10:04:19 -0700 

Message-Id: <199607061704.KAA25622@ravel.n2.net> 


X-Sender: k6sti@mail.n2.net 

X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 
To: mwcook@cris.com 

From: k6ésti@n2.net (Brian Beezley) 

Subject: UNKN422.WAV 

Cc: moon-net@vm.stlawu.edu, hfsig@tapr.org 


Mike, I wanted to tell you about my ongoing efforts to crack your 
UNKN422.WAV EME callsign mystery. I'm motivated primarily by the technical 
challenge; the $100 prize you offer will barely pay for the electricity I've 
expended! I think this is a really neat challenge you've come up with, so 
I'm copying this note to the EME reflector and to the TAPR HFSIG reflector 
(where there's recently been some discussion of CW decoding) in hopes of 
spurring others to try tackling the problem (perhaps one more time). 


Earlier this week I seriously looked at the problem for the first time. I 
spent the better part of two days on it. Listening to the file without 
benefit of signal processing, I could just barely hear a tone pop out of the 
noise for a second or two. (The first time I listened, I heard only noise.) 
This was so unexpected that I downloaded the file again 

(http: //www.webcom.com/af9y) to make sure I had the right one! 


I cobbled together a special version of DSP Blaster to process the .WAV file 
instead of real-time, sound-card audio. I found neither its LMS noise 
reduction nor 15-wpm matched filter helpful. 


For quite some time I've wondered whether a matched filter really is optimal 
for processing CW signals for detection by ear. A matched filter is optimal 
for threshold detection of signals in noise under certain conditions, but I 
wonder whether the conditions hold when preprocessing a signal for detection 
by ear. I don't know what the ear/brain does to detect CW, but it's 
certainly more complex than simple thresholding. For example, for many 
years I've preferred to use an SSB-bandwidth filter to recover weak HF CW 
signals rather than a 500-Hz CW filter. The additional noise somehow makes 
signal detection seem easier. (I haven't run a test to verify that it 
actually makes detection more reliable). I find listening through extremely 
narrow filters somewhat disconcerting because they shape the 
background-noise spectrum approximately to that of a sine wave at the filter 
center frequency. So your ear must then distinguish between the desired 
sine wave and weaker ones that bobble around in the background. Even though 
I estimate that DSP Blaster's 15-wpm matched filter improves CW detection by 
perhaps 1 dB for my ears, I sometimes prefer to detect CW in wideband noise 
(even though listening for long periods that way can be fatiguing). (It's 
interesting that most ops seem to vastly prefer narrowband CW filters.) 


Since UNKN422 remained a mystery, I tried implementing a signal-processing 
technique I had planned for DSP Blaster version 2. I've had my Pentium-100 
for one year and this was the first time I ever ran up against its 
processing-power limits. I had to recode the algorithm using 
Pentium-specific, floating-point optimizations (pipelining). It immediately 
yielded clearly audible dots and dashes throughout the .WAV file. Now I was 


getting somewhere! Right away I discovered I had misestimated the sending 
speed. I now was sure that recovering the callsign would be easy. I 
visualized the "K6STI Cracks UNKN422 with Secret Algorithm" headlines. So I 
listened carefully for some time, wrote down some possible calls, and 
consulted your list of 1000 EME callsigns, among which is the mystery 
callsign. Hmmmm...nothing matched very well. After more listening I found 
that I could mentally transform any given sound segment into my current 
best-guess callsign with very little wishful thinking! I was familiar with 
this phenomenon but thought I'd outgrown it years ago. I've heard 160-meter 
operators talk about it and I imagine it must be old-hat to you EME ops. 


Twice I was quite sure of the callsign. I was ready to submit my winning 
entry and thought I'd take one last listen. Then I discovered that I heard 
completely different letters by altering playback speed and pitch! This was 
quite a shock to someone who prides himself on his hearing acuity. Although 
the dots and dashes are readily audible, the signal level is quite variable. 
(I assume this is due to some kind of moon multipath.) Often the code 
elements seem to have holes in them or to be smeared together. Sometimes 
it's not clear whether it's one long dash or a dot and dash. I also 
discovered that my callsign choices tended to depend critically on one or 
two crucial letters. It was very easy to persuade myself to ignore other 
sounds that really didn't fit but clearly weren't important because, after 
all, surely this was the correct callsign! The fascinating thing about this 
problem is that it involves both a technical and psychological challenge. 


In frustration, I tried cascading a semi-matched filter with the 
processor-intensive technique. It didn't help. I really didn't want to 
guess at a callsign, so I kept listening over and over, tweaking algorithm 
constants. More new callsigns. I got so involved with the problem that my 
sleeping schedule became disrupted. When I reluctantly stopped listening to 
take a much-needed nap, I fitfully dreamed about weak CW! I decided it was 
time to return to normal life and finally gave up on the problem late one 
night. Temporarily. 


I have one more technical trick to pull. In fact, although it's not 
implemented in the current version, this trick was the whole reason I 
started the DSP Blaster project. I plan to implement this technique in 
version 2 along with the processor-intensive algorithm. I think the 
combination may provide enough S/N enhancement to yield a solution. It will 
take some experimentation to get right and a fair amount of programming to 
implement, so I expect it will be a little while in coming. Meanwhile, 
maybe someone else will decide to try a concerted attack on the problem. 


I think your UNKN422.WAV challenge would be a really neat term project for 
university engineering students. It's a fascinating mystery, involves 
signal-processing theory, practical engineering, programming techniques, and 
human perception and psychology. It's really a lot of fun! You might try 
to locate an engineering professor somewhere who is also a ham and lay it on 
him. 


73--Brian, K6STI 
k6sti@n2.net 


From k4jpj@appstate.campus.mci.net Sat Jul 06 18:51:26 1996 

Received: from appstate-01.campus.mci.net (appstate-01.campus.mci.net 
[204.71.75.162]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAAQ1661 for 
<hfsig@tapr.org>; Sat, 6 Jul 1996 18:51:24 -0500 (CDT) 

Received: from s01-pm02.appstate.campus.mci.net (s01-pm02.appstate.campus.mci.net 
[206.24.85.60]) by appstate-01.campus.mci.net (8.7.5/8.6.12) with SMTP id 
TAAOQ2284; Sat, 6 Jul 1996 19:51:17 -0400 (EDT) 

Message-Id: <199607062351.TAAQ2284@appstate-01.campus.mci.net> 

X-Sender: k4jpj@appstate.campus.mci.net 

X-Mailer: Windows Eudora Light Version 1.5.2 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sat, 06 Jul 1996 19:51:19 -0400 

To: bd7ix@amsat.org 

From: "Donald E. Haselwood" <k4jpj@appstate.campus.mci.net> 

Subject: Re: [HFSIG:1263] HELP, (TNC) 

Cc: hfsig@tapr.org 


At 08:44 PM 7/5/96 -0500, you wrote: 

>hello everybody, here is BD7IX(Lu Hui-Hua) from P.R.CHINA. 
>somedays ago, i send a mail at here , said want to know how 
>to made a modem(tnc) myself, my plan is use TCM3105 or 
>AM7910(7911) chip to do it, but unfortunate, the chip is 
>not produce. soi think maybe motorola's MC145442 OR MC145443 
>can replace it. but mc145442(3) only can use 300 baud 
>(CCITT V.21 OR BELL 103). 

>who can tell me the alternative else? 

>and if i use MC145442(3), who can give the circuit design about it? 
>please tell me via e-mail bd7ix@amsat.org 

>thanks 

> 

>Lu Hui-Huaxbd7ix* 

> 

> 

Lu Hui-Hua, 


I also have been looking for the TCM 3105 without success. I talked to 
Texas Instruments and they have it marked as an obsolete part (either out of 
production or due to go out of production soon). TI directed me to: 


MX-COM, Inc. 

4800 Bethania Station Road 
Winston-Salem, NC 27105-1201 
1-800-638-5577 

Fax: 910-744-5054 


Their part, MX 469, 1200 & 2400 bps MSK Modem, is very similar to the TCM 
3105. It has the Bell 202, but doesn't have the v23 feature. I have not 
studied the spec sheet closely, but it looks like the same circuit that was 
in the December 1995 QST, (p 39, IMP Modem), should work. The number of 
pins on the MX 469 is different than the TCM 3105 so the printed circuit 
board from FAR circuits would not work directly. 


73's 
Don, K4JPJ 


From forrerj@peak.org Sat Jul 06 22:39:12 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id WAAQ8567 for <hfsig@tapr.org>; Sat, 6 Jul 1996 
22:39:09 -0500 (CDT) 

Received: from p04.t0.monrotel.com (p00.tO.monrotel.com [198.68.25.33]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id UAA16114 for <hfsig@tapr.org>; Sat, 6 Jul 
1996 20:39:32 -0700 

Message-Id: <199607070339.UAA16114@PEAK.ORG> 

X-Sender: forrerj@peak.org (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sat, 06 Jul 1996 20:42:50 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1265] UNKN422.WAV 


Brian, 


>For quite some time I've wondered whether a matched filter really is optimal 
>for processing CW signals for detection by ear. A matched filter is optimal 
>for threshold detection of signals in noise under certain conditions, but I 
>wonder whether the conditions hold when preprocessing a signal for detection 
>by ear. I don't know what the ear/brain does to detect CW, but it's 
>certainly more complex than simple thresholding. For example, for many 
>years I've preferred to use an SSB-bandwidth filter to recover weak HF CW 
>signals rather than a 500-Hz CW filter. The additional noise somehow makes 
>signal detection seem easier. 


An interesting attempt. 


I always understood that the theory of matched filters relates to a 
decision-making process that assumes Gaussian noise. Having had some 
discussions with weak signal microwave experts, I have been reminded that 
microwave signals pretty much are like dealing with Gaussian noise and 
matched filters are probably a reasonable approach. This, however, may 
perhaps not hold for CW/RTTY decoding on HF, where I suspect adjacent 
channel suppression and good filter skirts may be more important. There are 
a couple of good arguments along these lines made in Frerking's book, if you 
would like to follow up on that. 


One other thing that you may give some thought; If the mystery CW is machine 
generated, it should have fairly accurate timing on the rising and falling 
edges. That then brings you to try sequency theory, i.e, doing FHT's (Fast 
Hademard Transforms) that may help recovering timing. 


The moral of the story is, and if my understanding of the challenge is 


correct, is that the signals are below the level that commonly-known methods 
can handle. You will need to pull some clever tricks. Like for example using 
sequency theory, where you are using information that is spread out over 
time, not only from what happens within a short time window. 


My 2 cents for what it's worth. Good luck with your efforts. 
--Johan 


From zs6awk@global.co.za Sun Jul 07 08:02:20 1996 

Received: from 1in01.global.co.za (1in01.global.co.za [196.3.164.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id IAA01943 for <hfsig@tapr.org>; Sun, 7 Jul 1996 
08:02:12 -0500 (CDT) 

Received: from anx_pt_1.global.co.za (anx_pt_1.global.co.za [196.3.165.201]) by 
lin01.global.co.za (8.7.3/8.7.3) with SMTP id PAA20481 for <hfsig@tapr.org>; Sun, 
7 Jul 1996 15:00:49 -0200 (GMT) 

Message-Id: <199607071700.PAA20481@1in01.global.co.za> 

X-Sender: zs6awk@mail.global.co.za 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sun, 07 Jul 1996 15:02:35 +0200 

To: hfsig@tapr.org 

From: zs6awk@global.co.za (Danie Brynard) 

Subject: vco block for simulink.. 


Does somebody know if simulink has a vco block and if not where can one get 
it ? I am considering to try a modem simulation on simulink but from what I 
hear there is no vco. (in the older versions in any way) 


regards, danie 


From zs6awk@global.co.za Sun Jul 07 08:42:33 1996 

Received: from 1in01.global.co.za (1lin01.global.co.za [196.3.164.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id IAA03333 for <hfsig@tapr.org>; Sun, 7 Jul 1996 
08:42:30 -0500 (CDT) 

Received: from anx_pt_1.global.co.za (anx_pt_3.global.co.za [196.3.165.203]) by 
lin01.global.co.za (8.7.3/8.7.3) with SMTP id PAA22273 for <hfsig@tapr.org>; Sun, 
7 Jul 1996 15:41:16 -0200 (GMT) 

Message-Id: <199607071741.PAA22273@1in01.global.co.za> 

X-Sender: zs6awk@mail.global.co.za 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sun, 07 Jul 1996 15:43:01 +0200 

To: hfsig@tapr.org 

From: zs6éawk@global.co.za (Danie Brynard) 

Subject: Re: [HFSIG:1256] Re: PSK Question.. 


>When designed for BPSK, both loops behave about 6 dB worse than a CW 
>PLL (i.e., an ordinary PLL without any means for removing PSK 
>modulation). When designed for QPSK, they're both about 12 dB 


>worse. This is for relatively strong signals that are above a certain 
>threshold. Even worse, there is an additional "squaring loss" that 
>depends on the signal-to-noise ratio in the loop that increases the 
>loss at low SNR. This behavior is inherent in a loop that removes 
>modulation -- it's not the fault of either the Costas or squaring loop 
>design. 

> 

>Phil 

> 

> 


Phil have you ever tried to see what the minimum SNR is for a computer 
simulation of a PLL ? I see in Gardner that he says that at low SNR's the 
PLL behaves differently due to non-linearities in the practical hardware. 
But in you computer simulations one can perhaps implement an ideal phase 
detector etc.... 


Gardners says ( I hope I understand correctly) that a typical PLL will hold 
in down to O0dB but acquire only at about 3 to 6dB input CW SNR. 


Regards, Danie 


From zs6awk@global.co.za Sun Jul 07 08:42:35 1996 

Received: from 1in01.global.co.za (1lin01.global.co.za [196.3.164.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id IAA03335 for <hfsig@tapr.org>; Sun, 7 Jul 1996 
08:42:32 -0500 (CDT) 

Received: from anx_pt_1.global.co.za (anx_pt_3.global.co.za [196.3.165.203]) by 
lin01.global.co.za (8.7.3/8.7.3) with SMTP id PAA22280 for <hfsig@tapr.org>; Sun, 
7 Jul 1996 15:41:19 -0200 (GMT) 

Message-Id: <199607071741.PAA22280@1in01.global.co.za> 

X-Sender: zs6awk@mail.global.co.za 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sun, 07 Jul 1996 15:43:04 +0200 

To: hfsig@tapr.org 

From: zs6awk@global.co.za (Danie Brynard) 

Subject: Re: [HFSIG:1255] Re: PSK Question.. 


Tom I found some nice explanations in Gardner. Busy reading.. 
73 danie 


>> 2) What is the minimum signal to noise required for the following BPSK 
>> demodulator techniques: 

>> 

>> - squaring loop PLL type 

>> - PSK Costas Loop 

>> - or perhaps what is the minimum SNR for a PLL to maintain phase lock ? 


> This is a difficult question to answer analytically, and I 
>think empirical results are more trustworthy. I think that the answer 
>is implementation dependent. No good references to give you right now. 


- Tom 


VV VV WV 


>Tom McDermott 
>mcdermot@aud.alcatel.com 
> 

> 


From chbrain@dircon.co.uk Sun Jul 07 12:14:08 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA12215 for <hfsig@tapr.org>; Sun, 7 Jul 
1996 12:14:03 -0500 (CDT) 
Received: by felix.dircon.co.uk id AA20578 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Sun, 7 Jul 1996 18:14:01 +0100 
Message-Id: <199607071714.AA20578@felix.dircon.co.uk> 
Received: from gw2-111.pool.dircon.co.uk(194.112.35.111) by amnesiac via smap 
(V1.3) 
id smaQ20557; Sun Jul 7 18:13:54 1996 
X-Sender: chbrain@popmail.dircon.co.uk 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Sun, 07 Jul 1996 18:05:26 +0100 
To: hfsig@tapr.org 
From: chbrain@dircon.co.uk (Charles Brain) 
Subject: Re: [HFSIG:1268] vco block for simulink.. 


>Does somebody know if simulink has a vco block and if not where can one get 
>it ? I am considering to try a modem simulation on simulink but from what I 
>hear there is no vco. (in the older versions in any way) 

> 

>regards, danie 

> 

> 

I am afraid I can't help you there Danie but PC-SIM has one and I 

managed to prove to myself that Costas Loops work ! 


73 Charles. 


From forrerj@peak.org Sun Jul 07 12:26:13 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id MAA12641 for <HFSIG@TAPR.ORG>; Sun, 7 Jul 1996 
12:26:11 -0500 (CDT) 

Received: from p03.t0.monrotel.com (p03.tO.monrotel.com [198.68.25.36]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id KAA17332 for <HFSIG@TAPR.ORG>; Sun, 7 Jul 
1996 10:26:35 -0700 

Message-Id: <199607071726.KAA17332@PEAK.ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 


Date: Sun, 07 Jul 1996 10:30:00 -0800 
To: HFSIG@tapr.org 

From: forrerj@peak.org (Johan Forrer) 
Subject: Q*2PSK 


Hi, 


Has anyone heard of Q*2PSK (quadrature-quadrature phase shift keying). This 
is a four dimensional constellation, i.e., both I and Q being QPSK 
modulated. It may be visualized as a hypercube with the four constellation 
points at it's corners. The waveform has a constant amplitude. 


I find very little about it in books, but have two papers about how it works 
from the British IEE Journal. 


Any further information will be appreciated. 
--Johan 


From JSANFORD@INFI.NET Sun Jul 07 13:31:33 1996 

Received: from mh004.infi.net (mailhost.infi.net [205.219.238.95]) by tapr.org 

(8.7.5/8.7.3/1.9) with ESMTP id NAA15578 for <hfsig@tapr.org>; Sun, 7 Jul 1996 

13:31:31 -0500 (CDT) 

Received: from pal5dsp11.orf.infi.net by mhO004.infi.net with SMTP 
(Infinet-S-3.3) id OAA24336; Sun, 7 Jul 1996 14:31:27 -0400 (EDT) 

Message-Id: <1.5.4.16.19960707183125 .23efa698@infi.net> 

X-Sender: jsanford@infi.net 

X-Mailer: Windows Eudora Light Version 1.5.4 (16) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sun, 07 Jul 1996 14:31:25 -0400 

To: hfsig@tapr.org 

From: Jim Sanford <JSANFORD@INFI.NET> 

Subject: Re: [HFSIG:1271] Re: vco block for simulink.. 


I'm about to order pc-sim ... can you share your file as a "learning" tool? 
Thanks & 73, Jim wb4gcs@amsat.org 


At 12:17 PM 7/7/96 -0500, you wrote: 

>>Does somebody know if simulink has a vco block and if not where can one get 
>>it ? I am considering to try a modem simulation on simulink but from what I 
>>hear there is no vco. (in the older versions in any way) 

>> 

>>regards, danie 

>> 

>> 

>I am afraid I can't help you there Danie but PC-SIM has one and I 

>managed to prove to myself that Costas Loops work ! 

> 

>73 Charles. 

> 

> 


From kchen@gala.apple.com Sun Jul 07 13:41:53 1996 

Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id NAA16052 for <hfsig@tapr.org>; Sun, 7 Jul 1996 
13:41:51 -0500 (CDT) 

Received: from atapple.apple.com ([17.128.100.40]) by mail-out2.apple.com 
(8.7.1/8.7.1) with ESMTP id LAA15698 for <hfsig@tapr.org>; Sun, 7 Jul 1996 
11:41:15 -0700 

Received: from gala.apple.com ([17.128.120.34]) by atapple.apple.com (8.7.1/8.7.1) 
with ESMTP id LAA10890 for <hfsig@tapr.org>; Sun, 7 Jul 1996 11:41:11 -0700 
Received: (from kchen@localhost) by gala.apple.com (8.7.1/8.7.1) id LAA20627 for 
hfsig@tapr.org; Sun, 7 Jul 1996 11:41:23 -0700 

Date: Sun, 7 Jul 1996 11:41:23 -0700 

From: Kok Chen <kchen@gala.apple.com> 

Message-Id: <199607071841.LAA20627@gala.apple.com> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1267] Re: UNKN422.WAV 


Johan (hi, Johan) wrote: 


One other thing that you may give some thought; If the mystery CW 
is machine generated, it should have fairly accurate timing on the 
rising and falling edges. That then brings you to try sequency 
theory, i.e, doing FHT's (Fast Hademard Transforms) that may help 
recovering timing. 


VV VV V 


Sequency filters (for example, described in H. F. Harmuth, 
"Nonsinusoidal Waves for Radar and Radio Communication," Academic 
Press, 1981) might work for decoding the _demodulated_ CW, but may 
not demodulate the mystery signal well, if the mystery signal was 
not using a Walsh function carrier (the FCC would frown on that, 
but Harmuth, and creatures who live in a Walsh space would love 
you). 


Using Hadamard transforms on the original UNKN422.WAV file may 
cause all sorts of spurs. Just as square waves create all sorts of 
spurs in a Fourier spectrum, a CW (presumably, sinusoidal) carrier 
would create a whole series of "Walsh-spurs" in a Hadamard spectrum. 


So, one has to still optimally "detect" or demodulate the recorded 
signal first, after which, _decoding_ using sequency filters may be 
an interesting technique. 


If one of us succeeds in decoding the UNKN422.WAV signal, it might 
help put the wetware-firmware debate on wreck.radio.amateur. policy 
to rest, HI. 

73 


Kok Chen, AA6TY kchen@apple.com 
Apple Computer, Inc. 


P.S. the Harmuth book has some interesting paragraphs on the Barker 
sequence that was earlier discussed on HFSIG. In fact, it mentions 
the "Complementary Codes" (sum of autocorrelation of the two 
"complementary" sequences have no sidelobes). Nice advantage of 
complementary codes is that it is not restricted to a maximum (known) 
length of 13. Ref: Golay, M. J., "Complementary Series", IRE Trans. 
Info. Theory, Vol 7, pp 82-87, 1961. GL es 73. 


From LANIER.R.A-@smtpgty.bwi.wec.com Mon Jul 08 07:00:51 1996 
Received: from tron.bwi.wec.com (tron.bwi.wec.com [129.228.4.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id HAAQ4570 for <hfsig@tapr.org>; Mon, 8 Jul 1996 
07:00:49 -0500 (CDT) 
Received: from smtpgty.bwi.wec.com by tron. bwi.wec.com; 
(5.65/1.1.8.2/31May95-0229PM) 
id AA12917; Mon, 8 Jul 1996 06:57:28 -0400 
Received: from ccMail by smtpgty.bwi.wec.com 
(IMA Internet Exchange 2.0 Enterprise) id 1EOF8BBO; Mon, 8 Jul 96 08:02:03 -0400 
Mime-Version: 1.0 
Date: Mon, 8 Jul 1996 07:56:03 -0400 
Message-Id: <1EOF8BBO.1858@smtpgty.bwi.wec.com> 
From: LANIER.R.A-@smtpgty.bwi.wec.com (LANIER.R.A-) 
Subject: Re: [HFSIG:1272] Q*2PSK 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


Johan, 


This sounds interesting! Could you please let me know what the 
articles are? 


73s de 
Tony, KE4ATO 


Subject: [HFSIG:1272] Q*2PSK 
Author: hfsig@tapr.org at BALT.SMTP 
Date: 7/7/96 12:38 PM 


Hi, 


Has anyone heard of Q*2PSK (quadrature-quadrature phase shift keying). This 
is a four dimensional constellation, i.e., both I and Q being QPSK 
modulated. It may be visualized as a hypercube with the four constellation 
points at it's corners. The waveform has a constant amplitude. 


I find very little about it in books, but have two papers about how it works 
from the British IEE Journal. 


Any further information will be appreciated. 


--Johan 


From forrerj@peak.org Mon Jul 08 14:41:57 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id OAA24453 for <HFSIG@TAPR.ORG>; Mon, 8 Jul 1996 
14:41:55 -0500 (CDT) 

Received: from p08.tO.monrotel.com (p08.tO.monrotel.com [198.68.25.41]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id MAA27283 for <HFSIG@TAPR.ORG>; Mon, 8 Jul 
1996 12:42:17 -0700 

Message-Id: <199607081942 .MAA27283@PEAK.ORG> 

X-Sender: forrerj@peak.org (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Mon, 08 Jul 1996 12:45:53 -0800 

To: HFSIG@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: QPSK Channel Spacing 


Hi, 


Thought I would share a bit feedback after my previous posting regarding why 
a system of orthogonally-spaced non-coherent QPSK channels does not seem to 
work very well. 


Just by co-incidence, I found the topic discussed in one of my favorite 
books; Please see Benedetto et. al: Digital Transmission Theory (ISBN 
0132143135). 


In essence, there is co-channel interference that degrades an 
orthoganally-spaced system. On page 291 he gives an analysis for channel 
spacing needed for a BER of 10-6 at a specified Eb/NO. 

For example, receiver bandwidth is optimal at 1.1*T which 
corresponds to a needed Eb/NO of 13 GB. 

On an equal basis, he shows Eb/No required for BER of 10-6 for 
different channel spacings. It is evident that for orthoganal channel 
Spacing (1.0*T), Eb/NO needs to be in excess of 20 dB. He shows a 
significant improvement when transmitter bandwidth is limited to 2.4*T, in 
which case a channel spacing of about 2.5*T needs an Eb/NO of 12dB for BER 
of 10-6. These spacings are further dependant whether the channels are keyed 
in synchronous or asynchronous fashion. 


(Note: T=symbol rate, i.e., 75 baud which corresponds to 150 bps for QPSK). 
Just for sake of comparison: 

Pactor II uses two parallel PSK waveforms each at 100 symbols/sec. According 
to above observations, this nicely fits into 2*(2.4«T)=480 Hz but would 
require an Eb/NO=12dB for a BER of 10-6. 


The scheme that I propose use channel spacing of (2.0*T) that fits four 


channels in 4*(2.0*75)=600 Hz with similar performance. 


--Johan 


From karn@unix.ka9q.ampr.org Tue Jul 09 00:55:32 1996 

Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id AAA24579 for <hfsig@tapr.org>; Tue, 9 Jul 
1996 00:55:30 -0500 (CDT) 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.3/8.6.12) id WAA14979; 
Mon, 8 Jul 1996 22:54:07 -0700 (PDT) 

Date: Mon, 8 Jul 1996 22:54:07 -0700 (PDT) 

Message-Id: <199607090554 .WAA14979@unix.ka9q.ampr.org> 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

To: chbrain@dircon.co.uk (Charles Brain) 

CC: hfsig@tapr.org 

In-reply-to: <199607020606.AA16754@felix.dircon.co.uk> (chbrain@dircon.co.uk) 
Subject: Re: [HFSIG:1252] Re: PC-DSP + PC-SIM 

Reply-To: karn@qualcomm.com 


>Does anyone know where to get a hold of GNUPLOT, I have searched 
>the COMPUSERVE archives and all I can find is the manual ! 


Like all GNU software, it's available on the Internet. Here's one place: 
ftp://prep.ai.mit.edu/pub/gnu/gnuplot-3.5.tar.gz 
--Phil 


From karn@unix.ka9q.ampr.org Tue Jul 09 02:25:29 1996 

Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id CAA27915 for <hfsig@tapr.org>; Tue, 9 Jul 
1996 02:25:27 -0500 (CDT) 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.3/8.6.12) id AAA15038; 
Tue, 9 Jul 1996 00:24:11 -0700 (PDT) 

Date: Tue, 9 Jul 1996 00:24:11 -0700 (PDT) 

Message-Id: <199607090724.AAA15038@unix.ka9q.ampr.org> 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

To: hfsig@tapr.org 

In-reply-to: <199607032357 .VAA05539@1in01.global.co.za> (zs6awk@global.co.za) 
Subject: Re: [HFSIG:1259] Re: PSK Question.. 

Reply-To: karn@qualcomm.com 


Danie, 


PLLs, being inherently nonlinear systems, are xextremelyx hard to 
analyze analytically. What analyses do exist generally make linearity 
assumptions such as S/N ratios large enough to keep the peak phase 
jitter small. Computer modeling is heavily used to simulate nonlinear 
performace such as lock-in behavior, and of course for the results to 
be useful you have to have initial conditions comparable to your own. 


If you've found Gardner, then you have xthex standard reference on 


PLLs. I believe Dr. Andrew Viterbi also published quite a bit of 
research into PLLs back in the 1960s. If you can find his mid 1960s 
book on Coherent Digital Communication you might find some further 
insights. 


My previous message mentioned "Squaring loss". The math to derive it 
quantitatively is quite hairy, but it can be qualitatively understood 
in several ways. One way is to consider that multiplying a noisy 
Signal by itself produces not only the desired signal times signal 
term but also unwanted terms consisting of noise times signal and 
noise times noise -- and these have spectral components that will go 
through the bandpass filter. At high SNR, the noise is small compared 
to the signal so the signal times signal term will dominate those 
involving noise, so the squaring loss is small. At low SNR this is not 
true. 


In a "decision directed" Costas loop, you can see squaring loss 
manifest itself as errors in the decisions. That is, when a 
constellation point crosses a decision threshold in the demodulator, 
the loop incorrectly guesses what the original signal was, and thereby 
comes up with an incorrect estimate of the error signal. 


Squaring loss is a serious problem in Costas loop demodulators 
operating at very low SNRs, such as in conjunction with a 
convolutional decoder and soft decisions. That's because a very large 
percentage of the hard-decoded symbols are in error, even though the 
decoder can easily handle the equivalent soft-decoded symbols. 


Phil 


From karn@unix.ka9q.ampr.org Tue Jul 09 02:27:26 1996 

Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id CAA27935 for <hfsig@tapr.org>; Tue, 9 Jul 
1996 02:27:24 -0500 (CDT) 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.3/8.6.12) id AAA15042; 
Tue, 9 Jul 1996 00:26:11 -0700 (PDT) 

Date: Tue, 9 Jul 1996 00:26:11 -0700 (PDT) 

Message-Id: <199607090726.AAA15042@unix.ka9q.ampr.org> 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

To: hfsig@tapr.org 

In-reply-to: <199607071726.KAA17332@PEAK.ORG> (forrerj@peak.org) 

Subject: Re: [HFSIG:1272] Q42PSK 

Reply-To: karn@qualcomm.com 


>Has anyone heard of Q*2PSK (quadrature-quadrature phase shift keying). This 
>is a four dimensional constellation, i.e., both I and Q being QPSK 


Say what? 


How do all the dimensions stay orthogonal? It's not possible to go 
beyond two dimensions on a single carrier and remain orthogonal. 


You could add another carrier and QPSK modulate that, but then that 
would just be OFDM-QPSK. 


Phil 


From dona@tridelta.com Tue Jul 09 07:41:10 1996 

Received: from wariat.apk.net (uucp@wariat.wariat.org [192.147.147.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id HAAQ6517 for <hfsig@tapr.org>; Tue, 9 Jul 1996 
07:41:08 -0500 (CDT) 

Received: from tridelta.com (uucp@localhost) by wariat.apk.net (8.7.5/8.7.3) with 
UUCP id IAA22114 for hfsig@tapr.org; Tue, 9 Jul 1996 08:41:07 -0400 (EDT) 
Received: from sparcy.tridelta.com (sparcy [192.160.168.222]) by tdi3.tridelta.com 
(8.6.9/8.6.9) with ESMTP id IAA26664 for <hfsig@tapr.org>; Tue, 9 Jul 1996 
08:24:47 -0400 

Received: from donapc.tridelta.com (donapc.tridelta.com [192.160.168.70]) by 
sparcy.tridelta.com (8.7.1/8.7.1) with SMTP id IAA05096 for <hfsig@tapr.org>; Tue, 
9 Jul 1996 08:24:19 -0400 (EDT) 

Date: Tue, 9 Jul 1996 08:24:19 -0400 (EDT) 

Message-Id: <199607091224.TAAQ5096@sparcy.tridelta.com> 

X-Sender: dona@sparcy 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: dona@tridelta.com (Don Adams) 

Subject: Re: [HFSIG:1276] QPSK Channel Spacing 


> 

>(Note: T=symbol rate, i.e., 75 baud which corresponds to 150 bps for QPSK). 
> 

>Just for sake of comparison: 

> 

>Pactor II uses two parallel PSK waveforms each at 100 symbols/sec. According 
>to above observations, this nicely fits into 2*(2.4*T)=480 Hz but would 
>require an Eb/NO=12dB for a BER of 10-6. 


Is this 400 bps total with 2 subcarriers? 


>The scheme that I propose use channel spacing of (2.0*T) that fits four 
>channels in 4*(2.0*75)=600 Hz with similar performance. 


Is this 600 bps total with 4 subcarriers? 


From forrerj@peak.org Tue Jul 09 10:29:24 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAA12725 for <hfsig@tapr.org>; Tue, 9 Jul 1996 
10:29:22 -0500 (CDT) 

Received: from p05.tO0.monrotel.com (p05.tO.monrotel.com [198.68.25.38]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id IAA21833 for <hfsig@tapr.org>; Tue, 9 Jul 
1996 08:29:44 -0700 

Message-Id: <199607091529. IAA21833@PEAK.ORG> 


X-Sender: forrerj@peak.org (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Tue, 09 Jul 1996 08:33:21 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1280] Re: QPSK Channel Spacing 


Don, 


>> 

>>(Note: T=symbol rate, i.e., 75 baud which corresponds to 150 bps for QPSK). 
>> 

>>Just for sake of comparison: 

>> 

>>Pactor II uses two parallel PSK waveforms each at 100 symbols/sec. According 
>>to above observations, this nicely fits into 2*(2.4«T)=480 Hz but would 
>>require an Eb/NO=12dB for a BER of 10-6. 

> 

>Is this 400 bps total with 2 subcarriers? 

> 

>>The scheme that I propose use channel spacing of (2.0*T) that fits four 
>>channels in 4*(2.0*75)=600 Hz with similar performance. 

> 

>Is this 600 bps total with 4 subcarriers? 

> 

> 

> 


Depends on what type of PSK: 


BPSK sends 1 bit/symbol, or 200 bps with two subcarriers at 100 baud each, 
QPSK sends 2 bits/symbol, or 400 bps with two subcarriers at 100 baud each, 
8-QPSK sends 3 bits/symbol, or 600 bps with two subcarriers at 100 baud each, 
16-QPSK sends 4 bits/symbol, or 800 bps with two subcarriers at 100 baud each. 


Both systems handle a variety of these depending on conditions. These bps 
rates of course does not take ECC or compression into account. ECC uses 
convolutional coding 

with varying rates; at good conditions punctured convolutional code rate 7/8 
is used that falls back to 1/2 when needed. Pactor II uses a form of 
Markov-Huffman data compression, meaning its on-the-fly coding/decoding 
table construction similar to LZW. 


My proposed system uses 75 baud symbols and it has a "robust" feature where 
speed is traded for robustness, i.e., at 8-DPQSK for example, each bit is 
repeated in 12 different slots and diversity combining is used. The 
effective bps rate is then 75 bps. 


It get quite involved when one need to see all the operating modes - there 
are several controlling factors that come into play. You may wonder how does 
the two ends of the conversation know what mode it's in? That is resolved by 


analysing the packet header where it carries the type of modulation, 
diversity factor, code rate etc... 


--Johan 


From kchen@apple.com Tue Jul 09 11:56:57 1996 

Received: from apple.com (apple.com [130.43.2.2]) by tapr.org (8.7.5/8.7.3/1.9) 
with SMTP id LAA16453 for <hfsig@tapr.org>; Tue, 9 Jul 1996 11:56:56 -0500 (CDT) 
Received: from 17.214.12.145 (A17-214-12-145.apple.com [17.214.12.145]) by 
apple.com (8.6.12/8.6.12) with SMTP id JAA20351 for <hfsig@tapr.org>; Tue, 9 Jul 
1996 09:56:51 -0700 

Message-ID: <31E28F60.16E5@apple.com> 

Date: Tue, 09 Jul 1996 09:57:04 -0700 

From: Kok Chen <kchen@apple.com> 

Reply-To: kchen@apple.com 

Organization: Apple Computer, Inc. 

X-Mailer: Mozilla 2.02 (Macintosh; I; 68K) 

MIME-Version: 1.0 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1278] Re: PSK Question.. 

References: <199607090724.AAA15038@unix.ka9q.ampr.org> 

Content-Type: text/plain; charset=us-ascii 

Content-Transfer-Encoding: 7bit 


Phil wrote: 


PLLs, being inherently nonlinear systems, are xextremelyx hard to 
analyze analytically. What analyses do exist generally make 
linearity assumptions such as S/N ratios large enough to keep the 
peak phase jitter small. 


VV VV 


For a nonlinear analysis of PLLs, try the library under author name 
Leon 0. Chua. I don't have the book with me here, but if someone 
is interested, I'll dig it out. Not too old, published within 2-5 
years, if memory serves. Title has the word "Chaotic" or something 
to do with Chaos theory in it somewhere. Forgot the second author's 
name too, sorry (They say memory is the _second_ thing to go!). 
Yep, a PLL works like a chaotic system, bifurcations and all! 


73 


Kok Chen, AA6TY kchen@apple.com 
Apple Computer, Inc. 


From zs6awk@global.co.za Tue Jul 09 15:32:08 1996 

Received: from 1in01.global.co.za (1in01.global.co.za [196.3.164.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id PAA25551 for <hfsig@tapr.org>; Tue, 9 Jul 1996 
15:32:05 -0500 (CDT) 

Received: from anx_pt_7.global.co.za (anx_pt_7.global.co.za [196.3.165.207]) by 
lin01.global.co.za (8.7.3/8.7.3) with SMTP id WAA24955 for <hfsig@tapr.org>; Tue, 
9 Jul 1996 22:30:47 -0200 (GMT) 

Message-Id: <199607100030.WAA24955@1in01. global.co.za> 

X-Sender: zs6awk@mail.global.co.za 


X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 
Date: Tue, 09 Jul 1996 22:32:40 +0200 

To: hfsig@tapr.org 

From: zs6awk@global.co.za (Danie Brynard) 
Subject: Re: [HFSIG:1282] Re: PSK Question.. 


Hi Kok. Can you give us the reference please ? 
danie 


>Phil wrote: 

> 

>> PLLs, being inherently nonlinear systems, are xextremelyx hard to 
>> analyze analytically. What analyses do exist generally make 

>> linearity assumptions such as S/N ratios large enough to keep the 
>> peak phase jitter small. 


>For a nonlinear analysis of PLLs, try the library under author name 
>Leon O. Chua. I don't have the book with me here, but if someone 
>is interested, I'll dig it out. Not too old, published within 2-5 
>years, if memory serves. Title has the word "Chaotic" or something 
>to do with Chaos theory in it somewhere. Forgot the second author's 
>name too, sorry (They say memory is the _second_ thing to go!). 
>Yep, a PLL works like a chaotic system, bifurcations and all! 

> 

>73 

> 

>Kok Chen, AA6TY kchen@apple.com 

>Apple Computer, Inc. 

> 

> 


From kchen@apple.com Tue Jul 09 18:42:18 1996 

Received: from apple.com (apple.com [130.43.2.2]) by tapr.org (8.7.5/8.7.3/1.9) 
with SMTP id SAAQ2390 for <hfsig@tapr.org>; Tue, 9 Jul 1996 18:42:16 -0500 (CDT) 
Received: from 17.214.12.145 (A17-214-12-145.apple.com [17.214.12.145]) by 
apple.com (8.6.12/8.6.12) with SMTP id QAA01635 for <hfsig@tapr.org>; Tue, 9 Jul 
1996 16:42:08 -0700 

Message-ID: <31E2EE68.4082@apple.com> 

Date: Tue, 09 Jul 1996 16:42:32 -0700 

From: Kok Chen <kchen@apple.com> 

Reply-To: kchen@apple.com 

Organization: Apple Computer, Inc. 

X-Mailer: Mozilla 2.02 (Macintosh; I; 68K) 

MIME-Version: 1.0 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1283] Re: PSK Question.. 

References: <199607100030.WAA24955@1in01.global.co.za> 

Content-Type: text/plain; charset=us-ascii 

Content-Transfer-Encoding: 7bit 


Danie, ZS6AWK, wrote: 


> Hi Kok. Can you give us the reference please ? 


OK, I had to track the book down, a colleague had borrowed it: 


Thomas S. Parker, L. O. Chua, "Practical Numerical Algorithms 
for Chaotic Systems," Springer-Verlag, N. Y., 1989. 
ISBN 0-387-96689-7 (also, apparently ISBN 3-540-96689-7) 


The book speaks more genericly of Chaotic equations, and not 
specifically of PLLs (only a couple of paragraphs on that). 
However, it references the following paper, which may be what 
I remembered: 


T. Endo, L. 0. Chua, "Chaos from phase-locked loops," IEEE Trans. 
Circuits and Systems, 987-1003, August 1988. 


73 


Kok Chen, AA6TY kchen@apple.com 
Apple Computer, Inc. 


From rick@itron-ca.com Tue Jul 09 19:31:29 1996 

Received: from itron-ca.com (gate.itron-ca.com [204.30.20.2]) by tapr.org 

(8.7.5/8.7.3/1.9) with SMTP id TAAQ3987 for <hfsig@tapr.org>; Tue, 9 Jul 1996 

19:31:27 -0500 (CDT) 

Received: (from audit@localhost) by itron-ca.com (8.6.9/8.6.9) id RAA12967 for 

<hfsig@tapr.org>; Tue, 9 Jul 1996 17:31:18 -0700 

Received: from unknown(204.30.20.214) by gate.itron-ca.com via smap (V1.3mjr) 
id smaQ12963; Tue Jul 9 17:30:36 1996 

Date: Tue, 9 Jul 96 17:26:26 PDT 

From: Rick Booth <rick@itron-ca.com> 

Subject: RE: [HFSIG:1283] Re: PSK Question.. 

To: hfsig@tapr.org 

X-PRIORITY: 3 (Normal) 

X-Mailer: Chameleon 5.0, TCP/IP for Windows, NetManage Inc. 

Message-ID: <Chameleon.836958891.rick@rickb.itron-ca.com> 

MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


There is a large pool of PLL work done by W.C Lindsey and his associates/students 
that is 
contained in the following ponderous text: 


Synchronization Systems in Communication and Control, W.C. Lindsey, Prentice Hall, 
ISBN 
0-13-879957-1 


Also, see: 
Principles of Coherent Communication, A.J. Viterbi, McGraw-Hill, 


and 


Phase Locked Loops, Roland Best, McGraw Hill, ISBN 0-07-911386-9 


Rick Booth 
'95 900SS SP 
E-mail: rick@itron-ca.com 


From BRYD@KIDD.CO.ZA Wed Jul 10 03:57:46 1996 
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id DAA25620 for <hfsig@tapr.org>; Wed, 10 Jul 1996 
03:57:39 -0500 (CDT) 
Received: from KIDD.CO.ZA by igw01 with smtp 
(Smail3.1.29.1 #3) id mOudv5R-OOOPB1C; Wed, 10 Jul 96 10:57 GMT+0200 
Received: from KenMail-Message_Server by KIDD.CO.ZA 
with Novell_GroupWise; Wed, 10 Jul 1996 11:04:14 +0200 
Message-Id: <sle38e2e.020@KIDD.CO.ZA> 
X-Mailer: Novell GroupWise 4.1 
Date: Wed, 10 Jul 1996 08:58:12 +0200 
From: Danie Brynard <BRYD@KIDD.CO.ZA> 
To: hfsig@tapr.org 
Subject: regarding ...'BPSK sends 1 bit/symbol' 


regarding ...'BPSK sends 1 bit/symbol' 


Johan does 1bit/symbol have the same meaning as 1bit/Hz ? Thus if you have only 
1Hz :-) it would be possible but 
the bitrate must be slow enough.. 


danie 


From dona@tridelta.com Wed Jul 10 07:11:11 1996 

Received: from wariat.apk.net (uucp@wariat.wariat.org [192.147.147.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id HAAQ0610 for <hfsig@tapr.org>; Wed, 10 Jul 1996 
07:11:09 -0500 (CDT) 

Received: from tridelta.com (uucp@localhost) by wariat.apk.net (8.7.5/8.7.3) with 
UUCP id IAA29360 for hfsig@tapr.org; Wed, 10 Jul 1996 08:11:08 -0400 (EDT) 
Received: from sparcy.tridelta.com (sparcy [192.160.168.222]) by tdi3.tridelta.com 
(8.6.9/8.6.9) with ESMTP id IAA28622 for <hfsig@tapr.org>; Wed, 10 Jul 1996 
08:10:53 -0400 

Received: from donapc.tridelta.com (donapc.tridelta.com [192.160.168.70]) by 
sparcy.tridelta.com (8.7.1/8.7.1) with SMTP id IAA07451 for <hfsig@tapr.org>; Wed, 
10 Jul 1996 08:10:27 -0400 (EDT) 

Date: Wed, 10 Jul 1996 08:10:27 -0400 (EDT) 

Message-Id: <199607101210.IAA07451@sparcy.tridelta.com> 

X-Sender: dona@sparcy 

X-Mailer: Windows Eudora Version 1.4.4 


Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 
To: hfsig@tapr.org 

From: dona@tridelta.com (Don Adams) 


Subject: Re: [HFSIG:1286] regarding ...'BPSK sends 1 bit/symbol' 
>regarding ...'BPSK sends 1 bit/symbol' 
> 


>Johan does 1bit/symbol have the same meaning as 1bit/Hz ? Thus if you have 
only 1Hz :-) it would be possible but 

>the bitrate must be slow enough.. 

> 

>danie 


Hi Danie I know Johan will have a technically better explanation, but a 

"real time" 

view of phase modulation I use is that frequency is the rate of change of phase. 
So the bandwidth depends on how fast U change the phase. 

eg If U instantly flip the phase 180 degrees, U get some "sharp corners" or 
some high frequency components or wide bandwidth. If U change the 

phase a 1/2cycle(180 degrees) per second, then the bandwidth is about 1/2Hz. 
This is why they're worried about the envelope of the rate of change of phase, 
to control the bandwidth. 

over and out...Don wa8qzz 


From forrerj@peak.org Wed Jul 10 10:57:42 1996 

Received: from PEAK.ORG (forrerj@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAAQ8681 for <hfsig@tapr.org>; Wed, 10 Jul 1996 
10:57:41 -0500 (CDT) 

Received: (from forrerj@localhost) by PEAK.ORG (8.6.13/8.6.7) id IAA13887; Wed, 10 
Jul 1996 08:58:04 -0700 

Date: Wed, 10 Jul 1996 08:58:04 -0700 (PDT) 

From: Johan Forre <forrerj@peak.org> 

X-Sender: forrerj@kira 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1286] regarding ...'BPSK sends 1 bit/symbol' 

In-Reply-To: <sle38e2e.020@KIDD.CO.ZA> 

Message-ID: <Pine.SUN.3.91.960710082801 .11200A-100000@kira> 

MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hallo Danie, 
Mmmm... No. bits per symbol does not say anything about 


the rate and thus occupied bandwidth. One would need to work in the baud 
rate to establish that. 


--Johan 


On Wed, 10 Jul 1996, Danie Brynard wrote: 


> regarding ...'BPSK sends 1 bit/symbol' 

> 

> Johan does 1bit/symbol have the same meaning as 1bit/Hz ? Thus if you have only 
1Hz :-) it would be possible but 

> the bitrate must be slow enough.. 

> 

> danie 

> 


> 
> 


From jbloom@arrl.org Wed Jul 10 14:43:51 1996 
Received: from mgate.arrl.org (root@mgate.arrl.org [205.217.201.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id 0AA17342 for <hfsig@tapr.org>; Wed, 10 Jul 1996 
14:43:49 -0500 (CDT) 
Received: from smtp_gw by mgate.arrl.org with smtp 
(Smail3.1.29.1 #9) id mOQue5As-OQOOfNDC; Wed, 10 Jul 96 15:43 EDT 
Message-Id: <mQue5As-OQOOfNDCO@mgate.arrl.org> 
Priority: urgent 
Date: Wed, 10 Jul 1996 16:38:00 -0400 
From: "Bloom, Jon, KE3Z" <jbloom@arrl.org> 
Subject: VISSIM 
To: "'hfsig@tapr.org'" <hfsig@tapr.org> 
X-Mailer: Worldtalk (NetConnex V4.00a) /MIME 


For some time, I've been using a Windows program called VisSim. This is a 
general-purpose system simulation program (for both continuous-time and 
discrete-time systems), although my exposure to it has been mostly in the 
context of control systems. VisSim allows you to construct a system as 
functional blocks, then run a simulation. 


Anyway, I wanted to mention this in my QEX editorial because you can 
download a working demo version of the program via the Web. So I went to 
the VisSim Web site to check that the demo version was still there and 
found that not only is it still there, they've added a demo communication 
system simulation add-on package. I've not had a chance to explore this 
add-on, but I thought I'd mention it here for those who may be 
interested. 


By the way, the demo version of VisSim is limited only in that it cannot 
save to disk. However, I discovered a neat trick. Since the entire system 
description is described in blocks you place in the VisSim window, and 
Since VisSim can copy and paste from the clipboard, you can select the 
entire system of blocks and copy it to the clipboard, then save it from 
Clipboard Viewer as a .CLP file. Later, you can load the .CLP file into 
Clipboard Viewer and then paste it back into the demo VisSim. The only 
thing this doesn't save, far as I can tell, is the simulation set-up 
data, which you can re-enter in a few seconds. (I haven't tried this 
technique with the comm system add-on.) 


I'd be interested to hear of the results if anyone tries out this add-on. 


Oh yeah: it's at http://www.vissim.com/ 
-- Jon, KE3Z 


From karn@qualcomm.com Wed Jul 10 20:06:01 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id UAA29006 for <hfsig@tapr.org>; Wed, 10 Jul 1996 
20:05:59 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
SAA25964; Wed, 10 Jul 1996 18:05:28 -0700 (PDT) 

Date: Wed, 10 Jul 1996 18:05:28 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607110105.SAA25964@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199607060152.PAA22253@aloha.com> (togo@of.net) 

Subject: Re: [HFSIG:1264] FECC Chipsets (and an apology) 


>What I am wondering, with CD's so popular, is it possible to adapt 
>CD-ROM chipsets to radio? I searched the web and the newsgroups, and 


Probably not. The CD "channel" is quite different from radio, so the 
design considerations for coding are different. An even bigger problem is 
the extremely high level of integration found in modern CD players, 

which makes it hard to get at just the pieces you want. 


On the other hand, general purpose CPUs are now getting so fast that 
you can do these functions in software at very respectable speeds. 


Phil 


From bm@lynx.ve3jf.ampr.org Wed Jul 10 22:07:58 1996 

Received: from lynx.ve3jf.ampr.org (lynx.ve3jf.ampr.org [44.135.96.100]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id WAAQ2898 for <hfsig@tapr.org>; Wed, 10 Jul 
1996 22:07:52 -0500 (CDT) 

Received: (from bm@localhost) by lynx.ve3jf£.ampr.org (8.6.12/8.6.12) id DAA17926 
for hfsig@tapr.org; Thu, 11 Jul 1996 03:07:59 GMT 

From: Barry McLarnon VE3JF <bm@lynx.ve3jf£.ampr.org> 

Message-Id: <199607110307 .DAA17926@lynx.ve3jf£.ampr.org> 

Subject: Re: [HFSIG:1276] QPSK Channel Spacing 

To: hfsig@tapr.org 

Date: Thu, 11 Jul 1996 03:07:58 +0000 (GMT) 

In-Reply-To: <199607081942 .MAA27283@PEAK.ORG> from "Johan Forrer" at Jul 8, 96 
02:52:51 pm 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 


Thought I would share a bit feedback after my previous posting regarding why 
a system of orthogonally-spaced non-coherent QPSK channels does not seem to 
work very well. 


Just by co-incidence, I found the topic discussed in one of my favorite 
books; Please see Benedetto et. al: Digital Transmission Theory (ISBN 


VV VV VV 


0132143135) . 


In essence, there is co-channel interference that degrades an 
orthoganally-spaced system. On page 291 he gives an analysis for channel 
spacing needed for a BER of 10-6 at a specified Eb/NO. 

For example, receiver bandwidth is optimal at 1.1*T which 
corresponds to a needed Eb/NO of 13 dB. 

On an equal basis, he shows Eb/No required for BER of 10-6 for 
different channel spacings. It is evident that for orthoganal channel 
Spacing (1.0*T), Eb/NO needs to be in excess of 20 dB. He shows a 
Significant improvement when transmitter bandwidth is limited to 2.4x*T, in 
which case a channel spacing of about 2.5*T needs an Eb/NO of 12dB for BER 
of 10-6. These spacings are further dependant whether the channels are keyed 
in synchronous or asynchronous fashion. 


(Note: T=symbol rate, i.e., 75 baud which corresponds to 150 bps for QPSK). 
Just for sake of comparison: 

Pactor II uses two parallel PSK waveforms each at 100 symbols/sec. According 
to above observations, this nicely fits into 2*(2.4«T)=480 Hz but would 
require an Eb/NO=12dB for a BER of 10-6. 


The scheme that I propose use channel spacing of (2.0*T) that fits four 
channels in 4*(2.0*75)=600 Hz with similar performance. 


VVVV VV VV VV VV VV VV VV VV VV VV WV 


Interesting... I'll have to try and find that book. I must admit that I 
don't understand this "co-channel interference" mechanism that you refer 
to... if the signals are truly orthogonal (which they are for 
noncoherent demodulation at 1/T channel spacing, if rectangular pulse 
shaping is used), where does the interference come from? There are a 
number of practical OFDM systems which use the minimum 1/T spacing, and 
I haven't come across any reference to performance penalties incurred by 
using this spacing... until now, that is. :-) Here are a few references 
which may be of interest: 


S.B. Weinstein and P.M. Ebert, "Data transmission by frequency division 
multiplexing using the discrete Fourier transform", IEEE Trans. Comm. 
Tech., vol. COM-19, pp. 628-634, Oct. 1971. 


L.J. Cimini, "Analysis and simulation of a digital mobile channel using 
orthogonal frequency division multiplexing", IEEE Trans. Commun., vol. 


COM-33, no. 7, pp. 665-675, July 1985. 


I'll look into this more tomorrow if I get some time... 


Barry 
Barry McLarnon VE3JF/VA3TCP | Internet: bm@hydra.carleton.ca 
Ottawa Amateur Radio Club | AMPRnet: bm@lynx.ve3jf£.ampr.org 


Packet Working Group | Web: http: //hydra.carleton.ca 


From karn@qualcomm.com Wed Jul 10 22:39:04 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id WAAQ3871 for <hfsig@tapr.org>; Wed, 10 Jul 1996 
22:39:02 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
UAA27140; Wed, 10 Jul 1996 20:38:29 -0700 (PDT) 

Date: Wed, 10 Jul 1996 20:38:29 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607110338.UAA27140@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199607071741.PAA22273@1in01.global.co.za> (zs6awk@global.co.za) 
Subject: Re: [HFSIG:1269] Re: PSK Question.. 


>Phil have you ever tried to see what the minimum SNR is for a computer 
>simulation of a PLL ? I see in Gardner that he says that at low SNR's the 
>PLL behaves differently due to non-linearities in the practical hardware. 
>But in you computer simulations one can perhaps implement an ideal phase 
>detector etc.... 


The idealness of the phase detector has nothing to do with it. A PLL is inherently 
a nonlinear system at low SNR, and even a perfect software emulation will 

slip cycles at low SNRs. Just as a perfect PSK demod will occasionally produce 
errors at low SNR. 


>Gardners says ( I hope I understand correctly) that a typical PLL will hold 
>in down to OdB but acquire only at about 3 to 6dB input CW SNR. 


PLL acquisition is another difficult-to-analyze subject. One thing 

that fast CPUs make possible is the notion of a whole bunch of virtual 

PLLs search the whole state space (frequency and phase) in "parallel", 
looking for the one that most closely matches. This way you don't have 

to open up your PLL loop bandwidths to speed up acquisition, which inherently 
degrades performance. 


Phil 


From BRYD@KIDD.CO.ZA Thu Jul 11 01:20:50 1996 
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id BAA15829 for <hfsig@tapr.org>; Thu, 11 Jul 1996 
01:20:47 -0500 (CDT) 
Received: from KIDD.CO.ZA by igw01 with smtp 
(Smail3.1.29.1 #3) id mOueF7B-OOOPIUC; Thu, 11 Jul 96 08:20 GMT+0200 
Received: from KenMail-Message_Server by KIDD.CO.ZA 
with Novell_GroupWise; Thu, 11 Jul 1996 08:27:26 +0200 
Message-Id: <stle4dbaee.009@KIDD.CO.ZA> 
X-Mailer: Novell GroupWise 4.1 
Date: Thu, 11 Jul 1996 08:19:49 +0200 
From: Danie Brynard <BRYD@KIDD.CO.ZA> 
To: hfsig@tapr.org 
Subject: Johan: 


Johan: 
Mmmm... No. bits per symbol does not say anything about the rate and thus 


occupied bandwidth. One would need 
to work in the baud rate to establish that. 


Ok Yes Johan, in Manchester II coding there is 1 bit per two symbols. 


danie 


From jmorriso@bogomips.com Thu Jul 11 01:31:48 1996 
Received: from orange.ConcordPacific.Com (root@orange.ConcordPacific.com 
[204.239.26.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA16010 for 
<hfsig@tapr.org>; Thu, 11 Jul 1996 01:31:46 -0500 (CDT) 
Received: from bogomips.com (root@jmorriso.multiactive.com [204.239.26.200]) by 
orange.ConcordPacific.Com (8.6.12/8.6.12) with SMTP id XAA12896 for 
<hfsig@tapr.org>; Wed, 10 Jul 1996 23:30:39 -0700 
Received: by bogomips.com (Linux Smail3.1.29.1 #3) 
id mOueFGk-O00TvfC; Wed, 10 Jul 96 23:30 PDT 
Message-Id: <mQueFGk-0Q00Tvf£C@bogomips. com> 
From: jmorriso@bogomips.com (John Paul Morrison) 
Subject: Re: [HFSIG:1290] Re: FECC Chipsets 
To: hfsig@tapr.org 
Date: Wed, 10 Jul 1996 23:30:34 -0800 (PDT) 
In-Reply-To: <199607110105.SAA25964@servo.qualcomm.com> from "Phil Karn" at Jul 
10, 96 08:21:04 pm 
X-Bogomips: 33.55 
X-Mailer: ELM [version 2.4 PL22] 
Content-Type: text 


>What I am wondering, with CD's so popular, is it possible to adapt 
>CD-ROM chipsets to radio? I searched the web and the newsgroups, and 


Probably not. The CD "channel" is quite different from radio, so the 
design considerations for coding are different. An even bigger problem is 
the extremely high level of integration found in modern CD players, 

which makes it hard to get at just the pieces you want. 


On the other hand, general purpose CPUs are now getting so fast that 
you can do these functions in software at very respectable speeds. 


VV VV VV VV VV WV 


Will the Intel MMX architecture help even more? 


BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM_ -- 
jmorriso@bogomips.com ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org 


From frode@dxcern.cern.ch Thu Jul 11 02:18:24 1996 


Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id CAA17425 for <hfsig@tapr.org>; Thu, 11 Jul 1996 
02:18:22 -0500 (CDT) 
Received: from dxcern.cern.ch (frode@dxcern.cern.ch [137.138.28.189]) by 
dxmint.cern.ch 

with SMTP id JAA04982 for <hfsig@tapr.org>; Thu, 11 Jul 1996 09:17:47 +0200 
(MET DST) 
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 

id AA27286; Thu, 11 Jul 1996 09:17:46 +0200 
Date: Thu, 11 Jul 1996 09:17:44 +0200 (MET DST) 
From: Frode Weierud <frode@dxcern.cern.ch> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1291] Re: QPSK Channel Spacing 
In-Reply-To: <199607110307 .DAA17926@lynx.ve3jf£.ampr.org> 
Message-Id: <Pine.ULT.3.91.960711085949 .26087A-100000@dxcern.cern.ch> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Wed, 10 Jul 1996, Barry McLarnon VE3JF wrote: 


Interesting... I'll have to try and find that book. I must admit that I 
don't understand this "co-channel interference" mechanism that you refer 
to... if the signals are truly orthogonal (which they are for 
noncoherent demodulation at 1/T channel spacing, if rectangular pulse 
shaping is used), where does the interference come from? There are a 
number of practical OFDM systems which use the minimum 1/T spacing, and 
I haven't come across any reference to performance penalties incurred by 
using this spacing... until now, that is. :-) Here are a few references 
which may be of interest: 


VV VV VV VV WV 


I too don't quite see the problem if the signals are truly orthogonal, 
but the problem is of course that in a medium like HF it is probably 
difficult to maintain the true orthogonality due to multipath effects and 
Doppler shift. This is of course the reason why most if not all 
multi-tone modems on HF use guard bands, to avoid sampling in the head 
and tail of each symbol. 


Thanks for the references. I have heard about the one from Weinstein and 
Ebert and I will have a look for them in the library. 


Here is yet another reference to modern OFDM modulation. 
Yiyan Wu and William Y. Zou, "Orthogonal Frequency Division Multiplexing: 
A Multi-Carrier Modulation Scheme", IEEE Transactions on Consumer 


Electronics, Vol. 41, No. 3, Aug. 1995, pp. 392-399. 


They also talk about the problem posed by multipath effects and the 
resulting ISI. Guard bands is the proposed solution. 


73, Frode, F/LA2RL 


Frode Weierud Phone : 41 22 7674794 
CERN, SL, CH-1211 Geneva 23, Fax : 41 22 7679185 


Switzerland E-mail : Frode.Weierud@cern.ch 


From LANIER.R.A-@smtpgty.bwi.wec.com Thu Jul 11 07:08:31 1996 
Received: from tron.bwi.wec.com (tron.bwi.wec.com [129.228.4.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id HAA25243 for <hfsig@tapr.org>; Thu, 11 Jul 1996 
07:08:29 -0500 (CDT) 
Received: from smtpgty.bwi.wec.com by tron. bwi.wec.com; 
(5.65/1.1.8.2/31May95-0229PM) 
id AAQ5514; Thu, 11 Jul 1996 07:40:03 -0400 

Received: from ccMail by smtpgty.bwi.wec.com 

(IMA Internet Exchange 2.0 Enterprise) id 1E4EEEBO; Thu, 11 Jul 96 08:09:15 
-0400 
Mime-Version: 1.0 
Date: Thu, 11 Jul 1996 08:01:39 -0400 
Message-Id: <1E4EEEBO.1858@smtpgty.bwi.wec.com> 
From: LANIER.R.A-@smtpgty.bwi.wec.com (LANIER.R.A-) 
Subject: Re: [HFSIG:1289] VISSIM 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


What is VisSim for? DSP simulation? Generic simulator? 


73s de 
Tony, KE4ATO 


Subject: [HFSIG:1289] VISSIM 
Author: hfsig@tapr.org at BALT.SMTP 
Date: 7/10/96 3:02 PM 


For some time, I've been using a Windows program called VisSim. This is a 
general-purpose system simulation program (for both continuous-time and 
discrete-time systems), although my exposure to it has been mostly in the 
context of control systems. VisSim allows you to construct a system as 
functional blocks, then run a simulation. 


Anyway, I wanted to mention this in my QEX editorial because you can 
download a working demo version of the program via the Web. So I went to 
the VisSim Web site to check that the demo version was still there and 
found that not only is it still there, they've added a demo communication 
system simulation add-on package. I've not had a chance to explore this 
add-on, but I thought I'd mention it here for those who may be 
interested. 


By the way, the demo version of VisSim is limited only in that it cannot 
save to disk. However, I discovered a neat trick. Since the entire system 
description is described in blocks you place in the VisSim window, and 
Since VisSim can copy and paste from the clipboard, you can select the 


entire system of blocks and copy it to the clipboard, then save it from 
Clipboard Viewer as a .CLP file. Later, you can load the .CLP file into 
Clipboard Viewer and then paste it back into the demo VisSim. The only 
thing this doesn't save, far as I can tell, is the simulation set-up data, 
which you can re-enter in a few seconds. (I haven't tried this technique 
with the comm system add-on.) 


I'd be interested to hear of the results if anyone tries out this add-on. 
Oh yeah: it's at http://www.vissim.com/ 


-- Jon, KE3Z 


From hakan.bergzen@enator.se Thu Jul 11 07:43:32 1996 
Received: from gk.enator.se ([147.13.200.1]) by tapr.org (8.7.5/8.7.3/1.9) with 
ESMTP id HAA26316 for <hfsig@tapr.org>; Thu, 11 Jul 1996 07:43:25 -0500 (CDT) 
Received: from janus.vxo.telub.se ([147.13.8.25]) by gk.gk.enator.se with SMTP id 
<55963>; Thu, 11 Jul 1996 14:36:14 +0100 
Received: from noak.vxo.enator.se by janus.vxo.telub.se with SMTP (PP) 
id <09786-0@janus.vxo.telub.se>; Thu, 11 Jul 1996 13:48:09 +0200 
Received: by noak with Microsoft Mail id <31EFF57D@noak>; 
Thu, 11 Jul 96 13:52:13 +02 
From: "Bergzen Hakan, KARL" <hakan.bergzen@enator.se> 
To: hfsig <hfsig@tapr.org> 
Subject: Digital voice 
Date: Thu, 11 Jul 1996 11:10:00 +0100 
Message-ID: <31EFF57D@noak> 
Encoding: 22 TEXT 
X-Mailer: Microsoft Mail V3.0 
MIME-Version: 1.0 
Content-Type: Text/plain; charset="US-ASCII" 
Content-Transfer-Encoding: 7bit 


Hello all, 

I just wondered whether anybody out there is experimenting with digital 
voice by using these moderate-to-high speed modems being discussed/develped 
in this newsgroup. 


Since the LPC10e algorithm requires 2400 bps, several of the modems being 
developed ought to be usable. Especially since it is somewhat error tolerant 
(therefore the possibility of using parallel tone modems with their 
assymptotically constant BER at high SNR's), thus no need for extensive FEC. 
I know of one company that has developed a reduced LPC10e vector set which 
only requires 600 bps. I haven't heard how it sounds yet though. Has anybody 
implemented the LPC10e in a standard low-cost DSP (e.g.TMS320xx or 
DSP56001), or even on a PC? 


Another route would be to use the digital voice modules now being embedded 
in the web reader programs (or as extensions thereof). One of these, from 
VoxWare, claims to use only 2400 bps. Would it be possible to hook it up to 
an HF modem, and if so, has anybody tried? 


Regards, 
Hakan (hakan.bergzen@enator.se) 


From goeppert@ruhp3.physik.uni-freiburg.de Thu Jul 11 08:06:48 1996 
Received: from ruhp3.physik.uni-freiburg.de (ruhp3.physik.uni-freiburg.de 
[132.230.77.3]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA27193 for 
<hfsig@tapr.org>; Thu, 11 Jul 1996 08:06:29 -0500 (CDT) 
Message-Id: <199607111306.IAA27193@tapr.org> 
Received: by ruhp3.physik.uni-freiburg.de 

(1.37.109.16/16.2) id AA291990422; Thu, 11 Jul 1996 15:07:02 +0200 
From: Reiner Goeppert <goeppert@ruhp3.physik.uni-freiburg.de> 
To: hfsig@tapr.org 
Date: Thu, 11 Jul 96 15:07:01 METDST 
Mailer: Elm [revision: 70.85] 


e-mail: goeppert@ruhp8.physik.uni-freiburg.de 
www: http://ruhp8.physik.uni-freiburg.de/goeppert/goeppert_home. html 
packet-radio: dliggq@dbOfrb.#bw.deu.eu 


From jbloom@arrl.org Thu Jul 11 10:34:13 1996 
Received: from mgate.arrl.org (root@mgate.arrl.org [205.217.201.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAAQ3925 for <hfsig@tapr.org>; Thu, 11 Jul 1996 
10:34:11 -0500 (CDT) 
Received: from smtp_gw by mgate.arrl.org with smtp 
(Smail3.1.29.1 #9) id mOueNkm-O000f49C; Thu, 11 Jul 96 11:34 EDT 
Message-Id: <mQueNkm-000f49C@mgate.arrl.org> 
Priority: urgent 
Date: Thu, 11 Jul 1996 12:08:00 -0400 
From: "Bloom, Jon, KE3Z" <jbloom@arrl.org> 
Subject: RE: [HFSIG:1296] Re: VISSIM 
To: "'hfsig@tapr.org'" <hfsig@tapr.org> 
X-Mailer: Worldtalk (NetConnex V4.00a) /MIME 


LANIER.R.A- wrote: 
> What is VisSim for? DSP simulation? Generic simulator? 


Generic would be a good way to say it. I suggest you look at the web 
paghe (http://www.vissim.com/), which is much more descriptive than I can 
be. 


-- Jon 


From forrerj@peak.org Thu Jul 11 11:42:25 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id LAAQ7325 for <hfsig@tapr.org>; Thu, 11 Jul 1996 
11:42:23 -0500 (CDT) 

Received: from p06.tO.monrotel.com (p06.tO.monrotel.com [198.68.25.39]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id JAAQ4535 for <hfsig@tapr.org>; Thu, 11 Jul 


1996 09:42:44 -0700 

Message-Id: <199607111642.JAAQ4535@PEAK.ORG> 
X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Thu, 11 Jul 1996 09:27:52 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1295] Re: QPSK Channel Spacing 


Hi Barry/Frode, 


>On Wed, 10 Jul 1996, Barry McLarnon VE3JF wrote: 

> 

>> Interesting... I'll have to try and find that book. I must admit that I 
>> don't understand this "co-channel interference" mechanism that you refer 
>> to... if the signals are truly orthogonal (which they are for 

>> noncoherent demodulation at 1/T channel spacing, if rectangular pulse 

>> shaping is used), where does the interference come from? 


I think this is the real issue ... the raised cosine pulse in my case, 
extends each symbol that it overlaps over xfourx symbols total, however, it 
conforms to all the requirements of a nyquist pulse. This, however, I 
suspect, will have some consequences to the orthoganality of the signals. In 
the reference I cited, there is no mention of OFDM, rather a discussion of 
FDM in general and what it takes in terms of TX and RX filtering to achieve 
a certain BER. 


In my last posts of the tests that I did, I hope I did not leave the 

impression that the guarded orthoganal signalling did not work?;In fact it 

does work very well if you don't apply any form of channel filtering at all. 

But we know what that a signal like that sounds like? I did then follow the 
procedures outlined for MIL-STD-188 filtering for the guarded pulses and saw 
the resultant degrading of the recovered constellations. So, my conclusion 

is that yes, it works, but if you apply filtering performance does take a 

hit as the channels are not truly orthogonal any longer. The question then 
answered by the reference I cited is how to practically live with what you have. 


My 2 cents worth - hope it helps a bit. 
--Johan 


From karn@qualcomm.com Thu Jul 11 21:41:50 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id VAAQ0882 for <hfsig@tapr.org>; Thu, 11 Jul 1996 
21:41:48 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
TAAO9374; Thu, 11 Jul 1996 19:41:17 -0700 (PDT) 

Date: Thu, 11 Jul 1996 19:41:17 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607120241.TAA09374@servo.qualcomm. com> 


To: hfsig@tapr.org 
In-reply-to: <mOueFGk-000TvfC@bogomips.com> (jmorriso@bogomips.com) 
Subject: Re: [HFSIG:1294] Re: FECC Chipsets 


>> On the other hand, general purpose CPUs are now getting so fast that 
>> you can do these functions in software at very respectable speeds. 


>Will the Intel MMX architecture help even more? 


Probably not for FEC, though it's possible that somebody might figure 
out a clever way to exploit it. 


For DSP, yes. This is what MMX is specifically designed to do. But it 
will be a while before MMX is widespread enough that you can write 
software in the expectation that most people will be able to use it. 


For those who don't know, the MMX (multimedia extensions) consist of 
additional instructions designed to aid in digital signal processing. 
The general approach is to perform basic operations on groups of four 
fixed-point samples at a time. This is a form of SIMD -- single 
instruction stream, multiple data stream. Intel calls the MMX data 
format "packed", because it packs four integers into a single word. 


Also, the MMX instructions perform arithmetic in a saturating fashion. 
That is, if you add 1 to FFFF in 16-bit arithmetic, you get FFFF 
instead of wrapping around to zero. This is important to reduce the 
otherwise nasty effects of an occasional overflow without having to 
follow each and every operation with a compare to detect and handle 
overflows. 


In the meantime, the Pentium floating point unit already makes a very 
capable DSP engine. Although operations can only be done on one pair 
of numbers at a time, the floating point unit is pipelined. While it 
takes 3 clock ticks to complete a typical FPU instruction, if you 
write your code carefully, you can "stage" a new FP instruction on 
xeveryx clock tick. In other words, you can execute up to three 
instructions in parallel at different stages of execution. All of the 
basic arithmetic instructions (add, subtract, multiply) can stage one 
instruction per clock, which pretty much qualifies the Pentium as a 
real DSP. 


The other week I was at the Smithsonian Air & Space museum where they 
have a Cray-1 supercomputer on display. The sign said it was capable of 
a sustained rate of 138 megaflops (million floating point instructions 
per second). Well, a 133 MHz Pentium running carefully written code 

can achieve one floating point operation per clock, or 133 megaflops. 
That makes it comparable to a Cray-1! Most impressive. 


Phil 
From bm@lynx.ve3jf.ampr.org Thu Jul 11 23:11:04 1996 


Received: from lynx.ve3jf.ampr.org (lynx.ve3jf.ampr.org [44.135.96.100]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id XAAQ4555 for <hfsig@tapr.org>; Thu, 11 Jul 


1996 23:11:01 -0500 (CDT) 

Received: (from bm@localhost) by lynx.ve3j£.ampr.org (8.6.12/8.6.12) id EAA19141 
for hfsig@tapr.org; Fri, 12 Jul 1996 04:11:02 GMT 

From: Barry McLarnon VE3JF <bm@lynx.ve3jf£.ampr.org> 

Message-Id: <199607120411.EAA19141@lynx.ve3jf£.ampr.org> 

Subject: Re: [HFSIG:1295] Re: QPSK Channel Spacing 

To: hfsig@tapr.org 

Date: Fri, 12 Jul 1996 04:11:02 +0000 (GMT) 

In-Reply-To: <Pine.ULT.3.91.960711085949 .26087A-100000@dxcern.cern.ch> from "Frode 
Weierud" at Jul 11, 96 02:27:30 am 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 


Frode Weierud writes: 

> I too don't quite see the problem if the signals are truly orthogonal, 

> but the problem is of course that in a medium like HF it is probably 

> difficult to maintain the true orthogonality due to multipath effects and 
> Doppler shift. This is of course the reason why most if not all 

> multi-tone modems on HF use guard bands, to avoid sampling in the head 

> and tail of each symbol. 


True, but in the analysis Johan refers to, I don't think impairments 
introduced by the channel are considered. The answer probably lies in 
non-rectangular shaping of the data, which destroys the n/T 
orthogonality. I think there is a tradeoff here... the OFDM approach 
makes good sense when there are a fair number of carriers (and a long 
symbol length), but perhaps raised-cosine weighting and greater 
separation than 1/T are more attractive when there are a small number of 
carriers, as in Johan's case. 


Thanks for the references. I have heard about the one from Weinstein and 
Ebert and I will have a look for them in the library. 


Here is yet another reference to modern OFDM modulation. 
Yiyan Wu and William Y. Zou, "Orthogonal Frequency Division Multiplexing: 


A Multi-Carrier Modulation Scheme", IEEE Transactions on Consumer 
Electronics, Vol. 41, No. 3, Aug. 1995, pp. 392-399. 


VV VV VV VV 


Good reference! Yiyan Wu works for the same organization as I do. :-) 
Here's one more: 


E.F. Casas and C. Leung, "OFDM for data communication over mobile radio 
FM channels - part 1: analysis and experimental results", IEEE Trans. 
Communications, vol. 39, no. 5, pp. 783-793, May 1991. 


Barry 
Barry McLarnon VE3JF/VA3TCP | Internet: bm@hydra.carleton.ca 
Ottawa Amateur Radio Club | AMPRnet: bm@lynx.ve3jf£.ampr.org 


Packet Working Group | Web: http: //hydra.carleton.ca 


From rs@ife.ee.ethz.ch Mon Jul 15 09:27:49 1996 

Received: from ife.ee.ethz.ch (ife-ifeO.ee.ethz.ch [129.132.25.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id JAA27489 for <hfsig@tapr.org>; Mon, 15 Jul 1996 
09:27:44 -0500 (CDT) 

Received: from gillespie.ee.ethz.ch (rs@gillespie.ee.ethz.ch [129.132.25.135]) by 
ife.ee.ethz.ch (8.7.5/8.7.5) with SMTP id QAA12593 for <hfsig@tapr.org>; Mon, 15 
Jul 1996 16:27:32 +0200 (MET DST) 

From: Rolf Sommerhalder <rs@ife.ee.ethz.ch> 

Received: by gillespie.ee.ethz.ch (8.6.11) id QAAQ7776; Mon, 15 Jul 1996 16:27:31 
+0200 

Message-Id: <199607151427 .QAA07776@gillespie.ee.ethz.ch> 

Subject: Re: [HFSIG:1272] Q42PSK 

To: hfsig@tapr.org 

Date: Mon, 15 Jul 1996 16:27:31 +0200 (MET DST) 

In-Reply-To: <199607071726.KAA17332@PEAK.ORG> from Johan Forrer at "Jul 7, 96 
12:38:58 pm" 

MIME-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 


> Has anyone heard of Q*2PSK (quadrature-quadrature phase shift keying). 
> I find very little about it in books, but have two papers about how it works 
> from the British IEE Journal. 


Try (though not available to me): 


[1] D. Saha, "Quadrature-quadrature phase shift keying", Ph.D. dissertation, 
Univ. Michigan, Aug. 1986. 


[2] ---, "Quadrature-quadrature phase shift keying", U.S. Pat. 4 680 777, 
July 1987. 

[3] ---, "Q2PSK - A new spectrally efficient modulation scheme", presented 
at the 21st Ann. Allerton Conf. Commun., Contr., Comput., Univ. Illinois, 
Oct. 1983. 


These refs are from: 

[4] D. Saha, T. G. Birdsall, "Quadrature-quadrature phase shift keying", 
IEEE Trans. Comm., Vol 37, No. 5, May 1989. 

or more recent papers about Q2PSK with more extensive reference lists 

(leading to most of the previously published papers on Q2PSK): 

[5] I. Korn, L. Wei, " Q2DPSK in the Satellite Mobile Channel with ISI and CSI", 
ICC Geneva, 1993. 

but be careful: the next paper [6] states that a claim in [4] is a fallacy ! 


[6] H. Sari, "A generalization of multidimensional modulation", 


1995 IEEE International Conference on Communications ICC '95: June 18-22, 
1995, Sheraton Seattle, Piscataway, NJ : IEEE Service Center, cop. 1995. 


Hope this helps. 


73, 
Rolf 


From karn@qualcomm.com Mon Jul 15 21:36:10 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id VAA28787 for <hfsig@tapr.org>; Mon, 15 Jul 1996 
21:36:08 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
TAA12604; Mon, 15 Jul 1996 19:35:35 -0700 (PDT) 

Date: Mon, 15 Jul 1996 19:35:35 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607160235.TAA12604@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199607151427 .QAAQ7776@gillespie.ee.ethz.ch> (message from Rolf 
Sommerhalder on Mon, 15 Jul 1996 09:45:02 -0500 (CDT)) 

Subject: Re: [HFSIG:1303] Re: Q*2PSK 


Here's the abstract to patent 4,680,777: 


Methods for modulating and demodulating digital data streams utilize a 
quadrature-quadrature phase shift keying data transmission arrangement 
to achieve a 100% increase in the bandwidth efficiency over known 
systems, such as minimum shift keying. Known arrangements utilize two 
dimensional data transmission. However, Q(%2) PSK, in accordance with 
the invention, provides four dimensional transmission which doubles 
the rate of data transmission for a given bandwidth, at the expense of 
approximately 45% increase in the average energy per bit. The input 
data stream is demultiplexed to form four demultiplexed data streams 
which are formed of demultiplexed data bits. Each such data stream is 
combined with a signal having carrier and data pulse-shaping 
components. Additionally, the data pulse-shaping components have a 
quadrature phase relationship with each other, thereby adding the 
additional two dimensions of data transmission capacity. 


Note the mention of a per-bit energy increase of 45%. This clearly 
implies that there's a cost for adding these two so-called 
"dimensions" that's not present when true multidimensional modulation 
is used (e.g., M-ary orthogonal FSK). In other words, the 4 so-called 
dimensions of Q-QPSK are not truly orthogonal, nor can they be without 
additional bandwidth. It also implies that this modulation is not 
particularly well suited to the power-limited channel, which in my 
opinion ought to include just about all of radio if it weren't for 
artificial bandwidth limits. 


Even on the bandwidth limited channel Q-QPSK must be compared to other 
16-ary modulation schemes such as 16-PSK and 16-ary QAM. Offhand I 
don't know what these other two schemes require in terms of extra 


Eb/NO over perfect QPSK, but I wouldn't be surprised if they're all 
comparable to or even better than Q-QPSK. 


Phil 


From Robert.Glassey@nmp.nokia.com Tue Jul 16 06:09:07 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id GAA20711 for <hfsig@tapr.org>; Tue, 16 Jul 1996 
06:09:02 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id 0AA12179 for <hfsig@tapr.org>; Tue, 
16 Jul 1996 14:08:30 +0300 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AA199585136; Tue, 16 Jul 1996 14:05:36 +0300 
X-Openmail-Hops: 2 
Date: Tue, 16 Jul 96 12:05:41 +0100 
Message-Id: <H0000292020ec174@MHS> 
In-Reply-To: <199607160235.TAA12604@servo.qualcomm. com> 
Subject: Q QPSK or not Q QPSK ? 
Sender: Robert.Glassey@nmp.nokia.com 
To: hfsig@tapr.org 


Here's the abstract to patent 4,680,777: 


Methods for modulating and demodulating digital data streams utilize a 
quadrature-quadrature phase shift keying data transmission arrangement 
to achieve a 100% increase in the bandwidth efficiency over known 
systems, such as minimum shift keying. Known arrangements utilize two 
dimensional data transmission. However, Q(42) PSK, in accordance with 
the invention, provides four dimensional transmission which doubles 
the rate of data transmission for a given bandwidth, at the expense of 
approximately 45% increase in the average energy per bit. The input 
data stream is demultiplexed to form four demultiplexed data streams 
which are formed of demultiplexed data bits. Each such data stream is 
combined with a signal having carrier and data pulse-shaping 
components. Additionally, the data pulse-shaping components have a 
quadrature phase relationship with each other, thereby adding the 
additional two dimensions of data transmission capacity. 


VV VV VV VV VV VV VV VV 


I think I understand now! 
This reminds me of PACTOR II. Except only one frequency is used. 


A pactor II symbol consists of two shaped pulses, roughly rased cosine 
(not sure what the exact shape is). Each pulse is 1 symbol of one of the 
two QPSK streams. The two pulses are overlayed so that one reaches a 
peak when the other reaches a trough, minimising interference between 
the two streams. In pactor II the two streams are also seperated in 
frequency to further reduce interference. Clover II is similar except 
four pulses, on four frequencies are used. 


Perhaps QQPSK simply uses the same frequency for the two QPSK streams, 


but with pulse shapes still out of phase. This could be viewed as a form 
of TDM, or more simply QPSK with symbols wider than the bit period 
(reducing bandwidth), but with pulse shapes phased such that there is 
little ISI. But is ISI really reduced? Over simply a square pulse twice 
as wide, yes, but I think ISI will still be significant, reducing Eb/No 
performance, hence the need for more Eb. 


If this is really what QQPSK is, then it's not so mysterious, and not 
truely 4 dimentional. But it is an interesting way of applying pulse 
shaping and deliberate ISI to trade off Eb/No for a bandwidth reduction. 


However I have heard of true 4 dimentional modulation in optics. The 
extra dimentions come from polarisation modulation. The four dimentions 
are I, Q, clockwise, anticlockwise (independent circular polarisations 
like + and - frequency, not antipodal). I recall a seminar back at 
university where Professor Desmond Taylor (a real fan of Veterbi and 
Ungerboch (sp?) coding) was explaining his 4 dimentional constalation 
and the trellis coding scheeme he was using to get optimal Veterbi 
decoding in 4D. At the time most of it went way over my head. I recall 
that the physical implementation of it involved mechanical devices that 
stretched various fiber paths to sync to the light beam. Weird stuff. 


Cheers, 
Rob, GOVTQ 


From karn@qualcomm.com Wed Jul 17 20:17:22 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id UAAQ0212 for <hfsig@tapr.org>; Wed, 17 Jul 1996 
20:17:20 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
SAA13777; Wed, 17 Jul 1996 18:16:49 -0700 (PDT) 

Date: Wed, 17 Jul 1996 18:16:49 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607180116.SAA13777@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <H0000292020ec174@MHS> (Robert.Glassey@nmp.nokia.com) 

Subject: Re: [HFSIG:1305] Q QPSK or not Q QPSK ? 


>little ISI. But is ISI really reduced? Over simply a square pulse twice 
>as wide, yes, but I think ISI will still be significant, reducing Eb/No 
>performance, hence the need for more Eb. 


Note that ISI cannot be overcome by increasing Eb/NO -- it must either 
be designed out with proper tx filtering, or compensated for at the rx 
with an equalizer. In some cases, deliberate ISI (e.g., duobinary) 

can be decoded with the Viterbi algorithm. 


>However I have heard of true 4 dimentional modulation in optics. The 
>extra dimentions come from polarisation modulation. The four dimentions 
>are I, Q, clockwise, anticlockwise (independent circular polarisations 
>like + and - frequency, not antipodal). I recall a seminar back at 


Yes, this would be a true four-dimensional scheme, and would not require 
any Eb/NO penalty. 


Don't let the notion of many dimensions warp your brain too 
much. "Dimensions" in modulation are just a fancy way to refer to 
setting channels that are independent of each other, i.e., orthgonal. 


Independence between multiple dimensions can be acquired in many ways: 
by the use of orthogonal basis functions in time (e.g., two BPSK 
signals in phase quadrature on the same frequency producing QPSK, FDM 
with sufficient carrier spacing to ensure orthogonality, or 
nonoverlapping time slots as in Clover or Pactor II), or use of 
physical means such as cross polarization. 


All of these schemes (except cross polarization, which you can only 
use once, i.e., to create two dimensions) exact their toll as you 
increase the number of dimensions: they use extra bandwidth. This is 
fundamental -- a scheme that pretends to add orthogonal dimensions 
without using extra total bandwidth (or reducing the bandwidth per 
orthogonal dimension) is NOT truly orthogonal, and MUST use a higher 
Eb/NO to achieve the same bit error rate. 


I have my doubts about schemes like Clover and Pactor II which walk 
sequentially through a series of carriers (4 for Clover, 2 for Pactor 
II). I understand why they do it -- to let the ISI die down before 
sending the next symbol on the same frequency channel. It's 
essentially a simplified form of frequency chirping, which is itself a 
form of frequency hopped spread spectrum, and that's a standard way to 
deal with multipath spread. But it would probably be better if they 
started by increasing (beyond 2) the number of orthogonal dimensions 
in their signal constellation, e.g., by going to M-ary FSK before they 
hop. That would cut down the symbol rate and the effects of ISI. 


Phil 


From jmorriso@bogomips.com Wed Jul 17 20:44:56 1996 
Received: from orange.ConcordPacific.Com (root@orange.ConcordPacific.com 
[204.239.26.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id UAAQ1226 for 
<hfsig@tapr.org>; Wed, 17 Jul 1996 20:44:51 -0500 (CDT) 
Received: from bogomips.com (root@jmorriso.multiactive.com [204.239.26.200]) by 
orange.ConcordPacific.Com (8.6.12/8.6.12) with SMTP id SAA05428 for 
<hfsig@tapr.org>; Wed, 17 Jul 1996 18:43:36 -0700 
Received: by bogomips.com (Linux Smail3.1.29.1 #3) 

id mOugi7n-O000TutC; Wed, 17 Jul 96 18:43 PDT 
Message-Id: <m0ugi7n-Q00TUtC@bogomips. com> 
From: jmorriso@bogomips.com (John Paul Morrison) 
Subject: Re: [HFSIG:1301] Re: FECC Chipsets 
To: hfsig@tapr.org 
Date: Wed, 17 Jul 1996 18:43:31 -0800 (PDT) 
In-Reply-To: <199607120241.TAA09374@servo.qualcomm.com> from "Phil Karn" at Jul 
11, 96 10:00:22 pm 
X-Bogomips: 33.55 


X-Mailer: ELM [version 2.4 PL22] 
Content-Type: text 


In the meantime, the Pentium floating point unit already makes a very 
capable DSP engine. Although operations can only be done on one pair 
of numbers at a time, the floating point unit is pipelined. While it 
takes 3 clock ticks to complete a typical FPU instruction, if you 
write your code carefully, you can "stage" a new FP instruction on 
xeveryx clock tick. In other words, you can execute up to three 
instructions in parallel at different stages of execution. All of the 
basic arithmetic instructions (add, subtract, multiply) can stage one 
instruction per clock, which pretty much qualifies the Pentium as a 
real DSP. 


VV VV VV VV VM 


Does the FPU run indepently of the CPU - ie can the CPU do other 
things, like schedule processes in a multi-tasking/multi-threaded 
OS, or fetch data to feed into the FPU? I'm just wondering whether 
"Native" Signal Processing hogs the whole processor, or whether 
you can keep other applications running. 


Anyone notice this: for some reason P133's "feel" a lot faster 
than their clock speeds would indicate. Maybe it's just better 
caching/motherboard design. 


BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM_ -- 
jmorriso@bogomips.com ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org 


From n4hy@ccr-p.ida.org Thu Jul 18 10:14:57 1996 

Received: from idacrd.ccr-p.ida.org (idacrd.ccr-p.ida.org [206.181.22.66]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAAQ4566 for <hfsig@tapr.org>; Thu, 18 
Jul 1996 10:14:55 -0500 (CDT) 

Received: from idacrd.ccr-p.ida.org (daemon@localhost) by idacrd.ccr-p.ida.org 
(8.7.2/8.7.2) with ESMTP id LAA25748 for <hfsig@tapr.org>; Thu, 18 Jul 1996 
11:15:37 -0400 (EDT) 

Received: from ccr-p.ida.org (xida.ccr-p.ida.org [198.3.6.62]) by idacrd.ccr- 
p.ida.org (8.7.2/8.7.2) with SMTP id LAA25744 for <hfsig@tapr.org>; Thu, 18 Jul 
1996 11:15:37 -0400 (EDT) 

Received: from growler.ccr-p.ida.org (growler.ccr-p.ida.org [198.3.6.3]) by ccr- 
p.ida.org (8.6.12/8.6.12) with ESMTP id LAA06284 for <hfsig@tapr.org>; Thu, 18 Jul 
1996 11:14:36 -0400 

From: Bob McGwier <n4hy@ccr-p.ida.org> 

Received: (from n4hy@localhost) by growler.ccr-p.ida.org (8.7.5/8.7.3) id LAA10408 
for hfsig@tapr.org; Thu, 18 Jul 1996 11:14:33 -0400 (EDT) 

Date: Thu, 18 Jul 1996 11:14:33 -0400 (EDT) 

Message-Id: <199607181514.LAA10408@growler.ccr-p.ida.org> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1269] Re: PSK Question.. 

In-reply-to: <199607071741.PAA22273@1in01.global.co.za> (zs6éawk@global.co.za) 


I am several days removed from this discussion as I have been backpacking in 
the Sangre de Cristos in New Mexico, but I have something to add at this 

late date. When the signal to noise ratio is low, you cannot even come close 
to making the "small angle" phase error assumption used to linearize the 
phase detectors and loops. You then truly have some serious nonlinearities 
and one MUST make use of the observational evidence during these periods to 
even come close to decent performance. The maximum likelihood estimator under 
white noise conditions (say a weak signal coming from space) is a nonlinear 
filtering estimator and smoother as a posteriori estimator of the signal state. 
It only took me four years of training for my Ph.D. in mathematics (stochastic 
processes and probability theory) to write a thesis on this topic. The 
sufficient statistic is a infinite dimensional estimator on a function space 
or Wiener path space and you can forget using it in an intelligent fashion. 


All is not lost however. 


You can make working suboptimal estimators that use some of the nonlinearities 
and I suggest that the best one for this group to consider is a version of 

the extended Kalman filter. It is the "linearized Phase lock loop" where you 
rederive the linearization at each estimate. If this proves insufficient to 
the task you can interate the procedure. That is, you derive the extended 
Kalman filter estimate in the forward time direction and use the new estimate 
of the state to rederive the "gains", innovations update, etc. and interate 
until you are satisfied (this can be until it "stops moving" or has been done 
a fixed or maximum number of times). The same can be done for the smoother 
going "backwards" in time and the two combine to make a practical if suboptimal 
a posteriori estimator. Since most DSP implementations cannot afford to 
keep the entire signal in the computer, some practical length must be forced 
on the forwards and backwards estimators for your "a posteriori" estimator. 


I wrote this hurriedly, and hope that at least get the flavor of what I am 
talking about. 


Bob 


From forrerj@peak.org Thu Jul 18 10:26:35 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAAQ5091 for <hfsig@tapr.org>; Thu, 18 Jul 1996 
10:26:33 -0500 (CDT) 

Received: from p05.tO0.monrotel.com (p05.tO.monrotel.com [198.68.25.38]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id IAAQ4851 for <hfsig@tapr.org>; Thu, 18 Jul 
1996 08:26:53 -0700 

Message-Id: <199607181526.IAAQ4851@PEAK.ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Thu, 18 Jul 1996 08:12:53 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1306] Re: Q QPSK or not Q QPSK ? 


Phil, 


>I have my doubts about schemes like Clover and Pactor II which walk 
>sequentially through a series of carriers (4 for Clover, 2 for Pactor 
>II). 


I'm not sure Pactor II falls in this category. As far as I know and the way 
I'm implementing their protocol, is that its simply two parallel DQPSK 
channels. There may be some phase adjustments for controlling crest factor, 
but not at all like Clover that uses both frequency and time interleaving 
such as described below. 


If anyone has seen real Pactor II waveform specifications or know that it's 
not straight DQPSK, please correct me. 


>I understand why they do it -- to let the ISI die down before 

>sending the next symbol on the same frequency channel. It's 
>essentially a simplified form of frequency chirping, which is itself a 
>form of frequency hopped spread spectrum, and that's a standard way to 
>deal with multipath spread. But it would probably be better if they 
>started by increasing (beyond 2) the number of orthogonal dimensions 
>in their signal constellation, e.g., by going to M-ary FSK before they 
>hop. That would cut down the symbol rate and the effects of ISI. 


This is quite interesting that you compare it to a form of frequency chirping. 
When one take an OFDM ensamble for example, and then adjust phases for 
minimal crest factor with some method like for example, Newman sequences, it 
produces a time-domain pulse that has striking resemblances to an up-chirp 
with a nearly flat amplitude. 


--Johan 


From rwhiting@winternet.com Thu Jul 18 20:27:27 1996 

Received: from absolut-zero.winternet.com (root@absolut-zero.winternet.com 
[198.174.169.4]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAAQ2265; Thu, 18 Jul 
1996 20:27:17 -0500 (CDT) 

Received: from LOCALNAME (ppp-67-74.dialup.winternet.com [204.246.67.74]) by 
absolut-zero.winternet.com (8.7.5/8.7.5) with SMTP id UAA19842; Thu, 18 Jul 1996 
20:25:41 -0500 (CDT) 

Date: Thu, 18 Jul 1996 20:25:41 -0500 (CDT) 

Posted-Date: Thu, 18 Jul 1996 20:25:41 -0500 (CDT) 

Message-Id: <199607190125.UAA19842@absolut-zero.winternet.com> 

X-Sender: rwhiting@mail.winternet.com 

X-Mailer: Windows Eudora Light Version 1.5.2 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: ham-digital@ucsd.edu, hfsig@tapr.org, netsig@tapr.org 

From: Rick Whiting <rwhiting@winternet.com> 

Subject: Digital Communications Conference 


1996 ARRL and TAPR Digital Communications Conference 
September 20-22, 1996 
Seattle, Washington (minutes from SeaTac airport) 


Web: http://www.tapr.org 


It's that time again! Time to make your travel plans and put the finishing 
touches on your work for the upcoming 15th Annual ARRL and TAPR Digital 
Communications Conference. This year marks the first year in which the ARRL 
Digital Communications Conference and TAPR Annual General Meeting have 
joined into one conference! 


The ARRL and TAPR Digital Communications Conference is an international 
forum for radio amateurs in digital communications, networking, and related 
technologies to meet, publish their work, and present new ideas and 
techniques for discussion. Presenters and attendees will have the 
opportunity to exchange ideas and learn about recent hardware and software 
advances, theories, experimental results, and practical applications. The 
Digital Communications Conference is not just for the digital expert, but 
for digitally-orientated amateurs of all levels of experience. 


The 1996 ARRL and TAPR Digital Communications Conference will be held on 
September 20-22, 1996 in Seattle, Washington. This year's conference 
location is just minutes away from the SeaTac (Seattle/Tacoma) Airport. 


Not only is the Digital Communications Conference technically stimulating, 
it is a weekend of fun for all who have more than a casual interest in any 
of the ham digital communications modes. This includes BBS operators, 
networkers, DX-Cluster Sysops, software writers, modem designers, and 
digital satellite communications enthusiasts. The ARRL and TAPR Digital 
Communications Conference is for all levels of digital operators -- a must 
conference to attend to get active on a national level. Now, more than ever, 
amateur radio needs this great meeting of the minds, since it is important 
that we demonstrate a continued need for the frequency allocations we now 
have by pushing forward and documenting our achievements. The ARRL and TAPR 
Digital Communications Conference is one of the few ways to record our 
accomplishments and challenge each other to do more. 


A Conference for the Beginner as well 


The conference is not just for the digital expert. This year's conference 
will again provide an entire morning with beginning and intermediate 
presentations on selected topics in digital communications. Some of the 
topics will include: APRS, Satellite Communications, TCP/IP, Digital Radio, 
Spread Spectrum and other introductory topics. Come to the conference and 
hear these topics presented by the experts! Don't miss this opportunity to 
listen and talk to others in this area. 


Workshops 


In addition to the presentation of papers on Friday and Saturday, three 
workshops will be held during the conference. On Friday, Keith Sproul, WU2Z, 
will hold a workshop on APRS packet-location software. Keith is the Chair of 
the TAPR APRS Special Interest Group, developer of the Macintosh and more 
recent co-developer of the Windows95 version of APRS, and a leader in the 
area of APRS technology. This is a unique opportunity to gain insight into 
this fast growing new digital aspect of amateur operations that combines 
computers, packet radio, and GPS (Global Positioning Satellites). On Sunday, 
Dewayne Hendricks, WA8DZP , will conduct a workshop focusing on "How to 
utilize Part 15 wireless Radios for Ham Applications." Dewayne is an expert 
in the area of commercial wireless systems; his company WarpSpeed 
Imagineering, focuses on wireless Internet connectivity. This workshop 
presents an opportunity to learn how Personal Communications Technology 
(handheld and small business wireless systems) can be used in the amateur 
service. A second Sunday workshop will focus on Wireless Networking using 
the WA4DSY 56K RF modem Technology. This workshop will focus on the 
technology and accessories of creating and maintaining 56K networks using 
the WA4DSY modem and equipment compatible with it such as routers, digital 
driver cards, transverters, and repeaters. Use of WA4DSY 56K equipment in 
the 219-220 band will also be discussed. 


1st Annual ARRL and TAPR DCC Student Papers Award 


ARRL and TAPR especially welcome papers from full time students to compete 
for the first annual student papers award. Two $500 travel awards will be 
given, one in each of the following categories: a) best 
technical/theory-oriented paper by a student, and b) best educational or 
community-oriented application paper by a student. The paper should relate 
directly to a wireless digital communication topic (see guidelines for more 
information). Papers coauthored by educators or telecommunications 
professionals are also eligible for this award, as long as a student is the 
first author. First year awards have been funded through a grant by The 
ARRL Foundation, Inc. Deadline for receipt of finished student paper 
manuscript: June 11, 1996. Please note that this deadline is different than 
the general conference submission date. For full details and paper 
guidelines contact TAPR or check http://www.tapr.org. 


Call for Papers 


Anyone interested in digital communications is invited to submit a paper for 
publication in the Conference Proceedings. Presentation at the Conference is 
not required for publication. If you know of someone who is doing great 
things with digital communications, be sure to personally tell them about 
this! Papers are due by July 23, 1996, and should be submitted to Maty 
Weinberg, ARRL, 225 Main Street, Newington, CT 06111 or via the Internet to 


lweinberg@arrl.org. Information on paper submission guidelines are available 
on-line (http://www.tapr.org). 


Local Co-Hosts 


The 1996 ARRL and TAPR Digital Communications Conference is co-hosted by the 
Puget Sound Amateur Radio TCP/IP Group and Boeing Employees Amateur Radio 
Society (BEARS). 


The Puget Sound Amateur Radio TCP/IP group is an informal group involved in 
an ongoing project to build and expand an amateur radio digital network in 
the greater Puget Sound area of the Pacific Northwest US. The Washington 
Experimenters TCP/IP Network (WETNET) uses TCP/IP as its primary transport 
protocol and currently has over 250 users. WETNET is linked to other amateur 
radio TCP/IP networks via the Internet. The Boeing Employees Amateur Radio 
Society (BEARS) is a general interest amateur radio club for employees of 
the Boeing Company, headquartered in Seattle, Washington. The BEARS are an 
active amateur club, supporting radio classes, VHF/UHF repeaters, and 
digital communications. BEARS has been instrumental in the construction of 
the Evergreen Intertie, an extensive network of interconnected repeaters in 
the Pacific Northwest. 


What can you expect during the 1996 ARRL and TAPR Digital Communications 
Conference ? 


*x A full day of papers and breakouts on Saturday for the beginner to the 
advanced amateur digital enthusiast. 


x Three workshops 
Friday (4pm) - APRS, Conducted by Keith Sproul, WU2Z 
Sunday (8am) - How to utilize Part 15 Radios for Ham Applications, 
Conducted by Dewayne Hendricks, WA8DZP 
Sunday (noon) - Wireless Networking using the WA4DSY 56K RF modem Technology 


x The first annual Student paper session. 

*x A banquet with Special Guest Speaker Lyle Johnson, WA7GXD 
Lyle was one of the founders of TAPR and instrumental in 
forming many of the current aspects of Amateur Digital 
Communications. He is currently very active in building 
several digital aspects of the upcoming Phase 3D satellite. 

* SIGs (Special Interest Groups) on Saturday following the banquet. 

* Informal get-togethers throughout the weekend. 

x A meeting facility that is perfect for this type of meeting. 


* Vendor area and informal engineering discussions/demonstrations. 


* An event at which the most important new developments in amateur digital 
communications are announced. 


* Digital 'movers and shakers' from all over the world in attendance. 


x Plenty of Washington State hospitality! 


Conclusion 


If you have attended a Digital Communications Conference in the past, just 
remember back to how much fun it was discussing the latest developments into 
the wee hours! If you have never been, then make your plans now to attend 
and find out how much fun the Digital Communications Conference can be. 


There are few activities where the importance of your participation can be 
so much fun and important! What a great way to share and renew your 
enthusiasm for digital amateur radio! Getting together with colleagues from 
all over the world and bringing each other up to date on your latest work. 
All this, and more, for an unforgettable weekend of ham radio and digital 
communications. Make your travel and lodging arrangements now. We hope to 
see you at the ARRL and TAPR Digital Communications Conference on September 
20-22! 


Full information on the conference and hotel information can be obtained by 
contacting Tucson Amateur Packet Radio, 8987-309 E. Tanque Verde Road #337, 
Tucson, AZ 85749-9399. Phone: (817) 383-0000. Fax: (817) 566-2544. Internet: 
tapr@tapr.org Web: www.tapr.org 


Sincerely, 
Steve Ford, WB8IMY, ARRL Conference Co-Chair 
Keith Justice, KF7TP, TAPR Conference Co-Chair 
Steve Stroh, N8GNJ, Local Host Liaison 
Greg Jones, WD5IVD, President TAPR 


Note: If you need handouts or flyers for meetings, contact TAPR about 
getting what you need! 


Hotel Information 


Conference presentations, meetings, and workshops will be held at the 
Quality Inn Seattle Airport, a complex co-located with the Radisson Hotel 
Seattle Airport. Rooms rates are $66/single-double and $76/triple. When 
making reservations with the hotel, be sure to indicate you are attending 
the ARRL and TAPR DCC conference. It is highly recommended that you book 
your room prior to arriving - a block of 75 rooms is reserved until 
September 6th, 1996. After the 75 rooms are booked, rooms will only be 
available in the Radisson hotel, but will be at a higher price. Be sure to 
book your rooms early! The hotel provides transportation to and from SeaTac 


Airport. You should contact the hotel to arrange airport transportation. 


Quality Inn Seattle Airport (conference hotel) 
17101 Pacific Highway South, Seattle, WA, 98188 
(206) 246-7000, Fax (206) 246-1715 


Radisson Hotel Seattle Airport (alternate hotel) 


17101 Pacific Highway South, Seattle, WA, 98188 
(206) 244-6000, Fax (206) 246-6835 


Registration 
Contact the TAPR office by Phone, Fax, or e-mail (Internet: tapr@tapr.org) 
to preregister or for additional meeting information. MasterCard and VISA 


accepted. 


- Preregistration (before Sept 1st) $40.00 x 


Late Registration or at door $45.00 x 


* - Conference Registration includes: 
Conference Proceedings, Sessions, Meetings, and Lunch. 


Saturday Evening Dinner (Limited Space) $19.00 xx 


xx - Dinner, Speaker: Lyle Johnson, WA7GXD, Prize Drawing 


Workshops 


APRS Workshop 
Friday, 4pm - 7pm. Conducted by Keith Sproul, WU2Z 


- Registration $15.00 


How to utilize Part 15 Radios for Ham Applications Workshop, Sunday, 8:00am 
- 11:00am. Dewayne Hendricks, WA8DZP 


- Registration $15.00 


Wireless Networking using the WA4DSY 56K RF modem Technology Workshop 
Sunday, 12noon - 3pm. 


- Registration $15.00 


Contact TAPR to register for the DCC. 

Tucson Amateur Packet Radio, 8987-309 E. Tanque Verde Road #337, Tucson, AZ 
85749-9399. Phone: (817) 383-0000. Fax: (817) 566-2544. 

Internet: tapr@tapr.org http: //www.tapr.org 


Richard A. (Rick) Whiting Phone: + 1 612 550 1213 
5780 Rosewood Ln. N. E-mail: rwhiting@winternet.com 
Plymouth, MN 55442-1411 Packet: WOTN @ WBOGDB.MN.USA.NOAM 


*xINDEPENDENT PROFESSIONAL CONSULTANT - TELECOMMUNICATIONS & WIRELESS* 


From BRYD@KIDD.CO.ZA Fri Jul 19 00:56:33 1996 
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id AAA17693 for <hfsig@tapr.org>; Fri, 19 Jul 1996 
00:56:29 -0500 (CDT) 
Received: from KIDD.CO.ZA by igw01 with smtp 
(Smail3.1.29.1 #3) id mOuh8Xy-OOOPHOC; Fri, 19 Jul 96 07:56 GMT+0200 
Received: from KenMail-Message_Server by KIDD.CO.ZA 
with Novell_GroupWise; Fri, 19 Jul 1996 08:02:23 +0200 
Message-Id: <stlef410f.002@KIDD.CO.ZA> 
X-Mailer: Novell GroupWise 4.1 
Date: Fri, 19 Jul 1996 07:57:19 +0200 
From: Danie Brynard <BRYD@KIDD.CO.ZA> 
To: hfsig@tapr.org 
Subject: Are the new amateur datacomms modulations and protocols 


freely available ? If not why not ? What mus 


Are the new amateur datacomms modulations and protocols freely available ? If not 
why not ? What must one do if 
you want to write a modem for a new emerging modulation/protocol ? 


Danie 


From kurpiers@zeus.uet.e-technik.th-darmstadt.de Fri Jul 19 01:52:50 1996 

Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by 

tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA19366 for <hfsig@tapr.org>; Fri, 19 Jul 

1996 01:52:46 -0500 (CDT) 

Received: from zeus (zeus.uet.e-technik.th-darmstadt.de [130.83.18.75]) by 

rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id IAA35914 for 

<hfsig@tapr.org>; Fri, 19 Jul 1996 08:52:31 +0200 

Received: from bacchus.uet.e-technik.th-darmstadt.de (bacchus.uet.e-technik. th- 

darmstadt.de [130.83.18.6]) by zeus (8.6.9/8.6.9-HRZ) with ESMTP id IAA25636 for 

<hfsig@tapr.org>; Fri, 19 Jul 1996 08:52:31 +0200 

Received: by bacchus.uet.e-technik.th-darmstadt.de (8.7.1/Forwarder-1.5/HRZ-THD) 
id IAA29457; Fri, 19 Jul 1996 08:50:35 +0200 

Date: Fri, 19 Jul 1996 08:50:35 +0200 (MET DST) 

From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1311] Are the new amateur datacomms modulations and protocols 

In-Reply-To: <stlef410f.002@KIDD.CO.ZA> 


Message-ID: <Pine.LNX.3.91.960719084458 .29452A-100000@bacchus.uet.e-technik.th- 
darmstadt.de> 

MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Fri, 19 Jul 1996, Danie Brynard wrote: 


> Are the new amateur datacomms modulations and protocols freely available ? If 
not why not ? What must one do if 

> you want to write a modem for a new emerging modulation/protocol ? 

> 

> Danie 

> 


I was talking to the developers of Pactor II the other week and they are 
not willing to make the Pactor II specs available freely. I really don't 
know any reason for this, but it is their decision. This means - at least 
for German amateurs - that it could be illegal to use Pactor II. 


73' Alexander 


ems Se ie I ea les ap a A al ate * 
| Alexander F. Kurpiers | | 
| Institut fuer Uebertragungs- | Voice: +49-6151-162369 | 
| u. Elektroakustik | Fax : +49-6151-165545 

| Merckstrasse 25 | EMail: a.kurpiers@uet.th-darmstadt.de | 
| D-64283 Darmstadt (Germany) | Hamradio: dl8aau@dbOzdf.#rpl.deu.eu | 
Feaee Secor seees'shhe se oreeesats Ha@ Seseoretoasshsss et scorstegse ose lee * 


From BRYD@KIDD.CO.ZA Fri Jul 19 09:28:29 1996 
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id JAAQ2706 for <hfsig@tapr.org>; Fri, 19 Jul 1996 
09:28:13 -0500 (CDT) 
Received: from KIDD.CO.ZA by igw01 with smtp 
(Smail3.1.29.1 #3) id mOuhGWm-QOOP5xC; Fri, 19 Jul 96 16:27 GMT+0200 
Received: from KenMail-Message_Server by KIDD.CO.ZA 
with Novell_GroupWise; Fri, 19 Jul 1996 16:33:43 +0200 
Message-Id: <stefb8e7.052@KIDD.CO.ZA> 
X-Mailer: Novell GroupWise 4.1 
Date: Fri, 19 Jul 1996 16:29:01 +0200 
From: Danie Brynard <BRYD@KIDD.CO.ZA> 
To: hfsig@tapr.org 
Subject: Alexander wrote.. 


Alexander wrote.. 

I was talking to the developers of Pactor II the other week and they are not 
willing to make the Pactor II specs 

available freely. I really don't know any reason for this, but it is their 
decision. This means - at least for German 

amateurs - that it could be illegal to use Pactor II. 


Ja very interesting. I feel the modulation standard and protocol should be widely 
published ie in ARRL Handbook. 


danie 


From forrerj@peak.org Fri Jul 19 10:48:20 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAAQ5708 for <hfsig@tapr.org>; Fri, 19 Jul 1996 
10:48:18 -0500 (CDT) 

Received: from p07.tO.monrotel.com (p07.tO.monrotel.com [198.68.25.40]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id IAAQ2480 for <hfsig@tapr.org>; Fri, 19 Jul 
1996 08:48:37 -0700 

Message-Id: <199607191548 . IAAQ2480@PEAK.ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Fri, 19 Jul 1996 08:34:47 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1312] Re: Are the new amateur datacomms modulations and 
protocols 


Alexander, 


That is a thorny question indeed. You are right that the new regulations in 
the US also requires that a protocol be "publicly published". I do have a 
sense though that Clover and Pactor both have been "grandfathered", i.e., 
by default accepted as legal. You will probably have a hard time obtaining 
implementation details beyond the sketcy glossy sales brochures. 


If you wish to develop a new scheme, why not discuss it on a forum like 
HFSIG - you will get some wonderful ideas and be able to use the knowledge 
of outstanding brains in the field. This way it is publicly available and 
legal. Further, I do believe that if you have plans to commercialize your 
idea, you will gain a lot more by promoting such an open architecture. There 
would be plenty of opportunity for innovation and technical advantages to 
offer. There is a lot to be said for doing a good job at both hardware and 
software that is available at a reason able price. In this field, acceptance 
by many users tells when something is successful. 


Time permitting at the Digital Communications Conference HFSIG meeting I 
will outline the new HF digital communications scheme that I am presently 
working on. It's called QUATOR and it will be an open architecture - all 
details will be freely available. Make a point to attend the DCC and give 
you an opportunity to give some input. 


My two cents worth. 


--Johan, KC7WW 


>On Fri, 19 Jul 1996, Danie Brynard wrote: 

> 

>> Are the new amateur datacomms modulations and protocols freely available 
? If not why not ? What must one do if 

>> you want to write a modem for a new emerging modulation/protocol ? 


>> Danie 


>I was talking to the developers of Pactor II the other week and they are 
>not willing to make the Pactor II specs available freely. I really don't 
>know any reason for this, but it is their decision. This means - at least 
>for German amateurs - that it could be illegal to use Pactor II. 

> 

>73' Alexander 


> 

> 

Deo oe eee eee Pe seeresoretsee Set eos Sect elect et eae sae * 
>| Alexander F. Kurpiers | 

>| Institut fuer Uebertragungs- | Voice: +49-6151-162369 | 
>| u. Elektroakustik | Fax : +49-6151-165545 

>| Merckstrasse 25 | EMail: a.kurpiers@uet.th-darmstadt.de | 
>| D-64283 Darmstadt (Germany) | Hamradio: d1l8aau@dbOzdf.#rpl.deu.eu | 
See eet eS Sei ee Ree }Pso Sete See Oe Bee eee See ee * 
> 
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From k6sti@n2.net Fri Jul 19 11:47:50 1996 

Received: from ravel.n2.net (ravel.n2.net [204.250.22.20]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id LAAQ8534 for <hfsig@tapr.org>; Fri, 19 Jul 1996 
11:47:46 -0500 (CDT) 

Received: from ppp179.n2.net (ppp179.n2.net [204.250.22.179]) by ravel.n2.net 
(8.6.12/8.6.12) with SMTP id JAA22300 for <hfsig@tapr.org>; Fri, 19 Jul 1996 
09:50:27 -0700 

Date: Fri, 19 Jul 1996 09:50:27 -0700 

Message-Id: <199607191650. JAA22300@ravel.n2.net> 

X-Sender: k6sti@mail.n2.net 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: késti@n2.net (Brian Beezley) 

Subject: Re: [HFSIG:1313] Alexander wrote.. 


>Alexander wrote.. 

>I was talking to the developers of Pactor II the other week and they are 
not willing to make the Pactor II specs 

>available freely. I really don't know any reason for this, but it is their 
decision. This means - at least for German 

>amateurs - that it could be illegal to use Pactor II. 


>Ja very interesting. I feel the modulation standard and protocol should be 
widely published ie in ARRL Handbook. 

> 

>danie 

> 


But you didn't expend the resources to develop the algorithm. SCS tells me 
they spent a very long time researching and testing the protocol. When you 
do that, you can't afford to give the final result away. I'd love to 
implement Pactor II myself, but I can understand why licenses aren't being 
offered cheap. 


73--Brian, K6STI 
k6sti@n2.net 


From JSANFORD@INFI.NET Fri Jul 19 15:12:28 1996 

Received: from mh004.infi.net (mailhost.infi.net [205.219.238.95]) by tapr.org 

(8.7.5/8.7.3/1.9) with ESMTP id PAA15756 for <hfsig@tapr.org>; Fri, 19 Jul 1996 

15:12:24 -0500 (CDT) 

Received: from pa9dsp7.orf.infi.net by mhO004.infi.net with SMTP 
(Infinet-S-3.3) id QAA29804; Fri, 19 Jul 1996 16:12:20 -0400 (EDT) 

Message-Id: <1.5.4.16.19960719201235.2eb739e2@infi.net> 

X-Sender: jsanford@infi.net 

X-Mailer: Windows Eudora Light Version 1.5.4 (16) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Fri, 19 Jul 1996 16:12:35 -0400 

To: hfsig@tapr.org 

From: Jim Sanford <JSANFORD@INFI.NET> 

Subject: Re: [HFSIG:1314] Re: Are the new amateur datacomms modulations 

and protocols 


At 10:56 AM 7/19/96 -0500, you wrote: 

>Alexander, 

> 

>That is a thorny question indeed. You are right that the new regulations in 
>the US also requires that a protocol be "publicly published". I do have a 
>sense though that Clover and Pactor both have been "grandfathered", i.e., 
>by default accepted as legal. You will probably have a hard time obtaining 
>implementation details beyond the sketcy glossy sales brochures. 


A good reason to support neither Pactor nor Clover by buying the products. 


Jim 
wb4gcs@amsat.org 


From wd6ehr@kaiwan009.kaiwan.com Fri Jul 19 16:21:44 1996 

Received: from kaiwan009.kaiwan.com (kaiwan009.kaiwan.com [198.178.203.9]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA17964 for <hfsig@tapr.org>; Fri, 19 
Jul 1996 16:21:42 -0500 (CDT) 

Received: (from wd6ehr@localhost) by kaiwan009.kaiwan.com (8.7.3/8.7.3) id 


OAA22484 for hfsig@tapr.org; Fri, 19 Jul 1996 14:21:29 -0700 (PDT) 
xxx KAIWAN Internet *x* 
From: Mike Curtis <wd6ehr@kaiwan009.kaiwan.com> 
Message-Id: <199607192121 .OAA22484@kaiwan009.kaiwan.com> 
Subject: Re: [HFSIG:1314] Re: Are the new amateur datacomms modulations and 
protocols 
To: hfsig@tapr.org 
Date: Fri, 19 Jul 1996 14:21:29 -0700 (PDT) 
In-Reply-To: <199607191548.TAAO2480@PEAK.ORG> from "Johan Forrer" at Jul 19, 96 
10:56:48 am 
X-Mailer: ELM [version 2.4 PL22] 
MIME-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 


That is a thorny question indeed. You are right that the new regulations in 
the US also requires that a protocol be "publicly published". I do have a 
sense though that Clover and Pactor both have been "grandfathered", i.e., 
by default accepted as legal. You will probably have a hard time obtaining 
implementation details beyond the sketcy glossy sales brochures. 


VVVV WV 


As I understand it, you could submit an article to QST, QRX, 73, etc., and 

this would qualify as "publicly published". I would even hazard the guess 

that sending a copy to the FCC and posting something to ALLUS would qualify 
as being "publicly published". The ARRL could probably clarify this. 


> If you wish to develop a new scheme, why not discuss it on a forum like 
> HFSIG 


Which might also qualify as being "publicly published". 


-- mike 


From k5yfw@www.kelly-afb.org Fri Jul 19 16:27:58 1996 

Received: from www.kelly-afb.org (www.kelly-afb.org [204.214.204.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id QAA18045 for <hfsig@tapr.org>; Fri, 19 Jul 1996 
16:27:56 -0500 (CDT) 

Received: (from k5yfw@localhost) by www.kelly-afb.org (8.7.1/8.7.1) id QAA10251 
for hfsig@tapr.org; Fri, 19 Jul 1996 16:27:14 -0500 (CDT) 

From: Walt DuBose - K5YFW <k5yfw@www.kelly-afb.org> 

Message-Id: <199607192127 .QAA10251@www.kelly-afb.org> 

Subject: Twin Cities 

To: hfsig@tapr.org 

Date: Fri, 19 Jul 1996 16:27:14 -0500 (CDT) 

In-Reply-To: <199607190125 .UAA19842@absolut-zero.winternet.com> from "Rick 
Whiting" at Jul 18, 96 08:42:34 pm 

Reply-To: k5yfw@www.kelly-afb.org 

X-Mailer: ELM [version 2.4 PL24] 

Content-Type: text 


Rick, 


Was in the Twin Cities Sun nite thru this morning but didn't have time to 
ham as my son was taking us (Susie, WB5WXY and I) out to Manny's, to 
Stillwater, other fine resturants and his Buca resturant out in Eden 
Prairie. Also took a boot ride from St Paul and of course visited the 
"Mall". 


Spent too much money so may have to pass on Seattle but I'm still hoping 
Mama will let me "charge" a round trip ticket...Hi Hi. 


73, 
Walt 


PS, we're off to Boise, ID in the morning to see my other son and our 
granddaughter...we're keeping the airlines in money. 


| The MicroSoft operating system didn't get as bad as it is overnight, | 
| it has taken over 10 years of careful, calculated development. | 


| The greatest dangers to liberty 
Walt DuBose - K5YFW | lurk in insidious encroachment 
E-Mail k5yfw@www.kelly-afb.org | by men of zeal, well-meaning 
Business Telephone: (210)925-6081 | but without understanding. 
Home Telephone: (210)696-3196 | | 
| - Justice Louis D. Brandeis | 


From wd5ivd@tapr.org Fri Jul 19 17:02:57 1996 

Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id RAA19211 for 
hfsig@tapr.org; Fri, 19 Jul 1996 17:02:56 -0500 (CDT) 

From: Greg Jones <wd5ivd@tapr.org> 

Message-Id: <199607192202.RAA19211@tapr.org> 

Subject: Re: [HFSIG:1317] Re: Are the new amateur datacomms modulations and 
protocols 

To: hfsig@tapr.org 

Date: Fri, 19 Jul 1996 17:02:55 -0500 (CDT) 

In-Reply-To: <199607192121.0AA22484@kaiwan009.kaiwan.com> from "Mike Curtis" at 
Jul 19, 96 04:25:27 pm 

X-Mailer: ELM [version 2.4 PL25] 

Content-Type: text 


The ARRL has a publication that discusses the Clover, Pactor and GTOR. 
These were presented at the 13th DCC I believe -- which was when the FCC 
made the statement about publishing a standard to make it legal 


The acceptable method within the US has been to publish it in the Digital 
Communication Conference. 


ep) 

wR 

ip) 
iio} 


That is a thorny question indeed. You are right that the new regulations in 
the US also requires that a protocol be "publicly published". I do have a 
sense though that Clover and Pactor both have been "grandfathered", i.e., 
by default accepted as legal. You will probably have a hard time obtaining 
implementation details beyond the sketcy glossy sales brochures. 


VVVV WV 


As I understand it, you could submit an article to QST, QRX, 73, etc., and 

this would qualify as "publicly published". I would even hazard the guess 

that sending a copy to the FCC and posting something to ALLUS would qualify 
as being "publicly published". The ARRL could probably clarify this. 


> If you wish to develop a new scheme, why not discuss it on a forum like 
> HFSIG 


Which might also qualify as being "publicly published". 


-- mike 


VVVV VV VV VV VV VV VV VV VV VV WV 


From choffman@pelican.davlin.net Fri Jul 19 19:37:04 1996 

Received: from pelican.davlin.net (root@pelican.davlin.net [206.245.221.3]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id TAA24226 for <hfsig@tapr.org>; Fri, 19 Jul 
1996 19:36:59 -0500 (CDT) 

Received: from davlin.davlin.net (cc-dup-57.davlin.net [206.245.221.57]) by 
pelican.davlin.net (8.6.12/8.6.9) with SMTP id TAA21644 for <hfsig@tapr.org>; Fri, 
19 Jul 1996 19:42:27 -0500 

Message-Id: <1.5.4.32.19960720003528 .0069e128@davlin.net> 

X-Sender: choffman@davlin.net 

X-Mailer: Windows Eudora Light Version 1.5.4 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Fri, 19 Jul 1996 19:35:28 -0500 

To: hfsig@tapr.org 

From: Charles Hoffman <choffman@pelican.davlin.net> 

Subject: Re: [HFSIG:1318] Twin Cities 


Not sure how you will get this Walt! If you do, check out the Southwest 
Airlines...in a bigtime price war and their tickets are going pretty cheep 
where ever they service. Glad you are having ooodles of fun...its only 
moola...enjoy. black walnuts tincture is done FB. 


At 16:45 7/19/96 -0500, you wrote: 

>Rick, 

> 

>Was in the Twin Cities Sun nite thru this morning but didn't have time to 
>ham as my son was taking us (Susie, WB5WXY and I) out to Manny's, to 


>Stillwater, other fine resturants and his Buca resturant out in Eden 
>Prairie. Also took a boot ride from St Paul and of course visited the 
>"Mall". 

> 

>Spent too much money so may have to pass on Seattle but I'm still hoping 
>Mama will let me "charge" a round trip ticket...Hi Hi. 

> 

>73, 

> 

>Walt 

> 

>PS, we're off to Boise, ID in the morning to see my other son and our 
>granddaughter...we're keeping the airlines in money. 


>| The MicroSoft operating system didn't get as bad as it is overnight, | 
>| it has taken over 10 years of careful, calculated development. | 


| The greatest dangers to liberty | 
>| Walt DuBose - K5YFW | lurk in insidious encroachment | 
>| E-Mail k5yfw@www.kelly-afb.org | by men of zeal, well-meaning | 
>| Business Telephone: (210)925-6081 | but without understanding. | 
>| Home Telephone: (210)696-3196 | 

| - Justice Louis D. Brandeis | 


From karn@qualcomm.com Fri Jul 19 20:52:12 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id UAA26498 for <hfsig@tapr.org>; Fri, 19 Jul 1996 
20:52:09 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
SAA04696; Fri, 19 Jul 1996 18:51:37 -0700 (PDT) 

Date: Fri, 19 Jul 1996 18:51:37 -0700 (PDT) 

From: Phil Karn <karn@qualcomm.com> 

Message-Id: <199607200151.SAA04696@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <m0ugi7n-000TutC@bogomips.com> (jmorriso@bogomips.com) 

Subject: Re: [HFSIG:1307] Re: FECC Chipsets 


>Does the FPU run indepently of the CPU - ie can the CPU do other 
>things, like schedule processes in a multi-tasking/multi-threaded 


Read the Intel architecture documents. The FPU is a separate unit in 
the Pentium, but it executes off the same instruction stream. The 
Pentium also has two integer pipeline units, although the second can't 
handle every instruction. 


The CPU control logic attempts to keep as many of the units going in 


parallel as possible as it executes a single instruction stream. So in 
that sense, no, the FPU doesn't really run independently of the CPU. 


Also, each unit can generally work at once on several consecutive 
instructions in different stages of execution, like an assembly line. 
This is pipelining. For example, the Pentium floating point unit takes 
three clocks to finish a multiply (or to do most basic floating point 
operations other than divide), but because the unit is pipelined it 
can begin a new multiply instruction before the previous one (or two) 
have completed. 


The CPU's ability to do all this depends heavily on the actual 
instruction sequence; that's why the clock counts in the manual vary 
so much. Really good compilers know how the Pentium works inside, so 
they'll try to emit code that can be readily pipelined. For example, 
they'll try to avoid emitting instructions that immediately access the 
result of the previous instruction, because that causes a pipeline 
"stall" -- the CPU blocks until the needed data is ready before 
proceeding, which slows things down. A good compiler will see if it 
can do something else instead until the needed data is ready. 


Unfortunately, I don't have one of those compilers so for the stuff I 
really want to run fast, I'll write hand-optimized assembler designed 
to pipeline well. I've done this for a FFT (specifically a radix 4 FFT 
butterfly) and for a FIR. 


The Pentium Pro has many more performance speedups, including 
out-of-order execution of unrelated instructions (meaning the compiler 
doesn't have to be as smart to avoid pipeline stalls) and "speculative 
execution" of multiple instructions so as to get a head start before 
it's known which should actually have been done (e.g., after a 
branch). See Intel's web pages for more details. 


Phil 


From chbrain@dircon.co.uk Sat Jul 20 05:35:47 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id FAA16917 for <hfsig@tapr.org>; Sat, 20 Jul 
1996 05:35:43 -0500 (CDT) 
Received: by felix.dircon.co.uk id AA14792 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 20 Jul 1996 11:35:30 +0100 
Message-Id: <199607201035.AA14792@felix.dircon.co.uk> 
Received: from gw2-135.pool.dircon.co.uk(194.112.35.135) by amnesiac via smap 
(V1.3) 


id sma014778; Sat Jul 20 11:35:15 1996 
X-Sender: chbrain@popmail.dircon.co.uk 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Sat, 20 Jul 1996 11:24:31 +0100 
To: hfsig@tapr.org 
From: chbrain@dircon.co.uk (Charles Brain) 


Subject: ECC Book 
Has anybody seen this book and if so is it worth adding to the ‘'library' ?. 


Error Coding Cookbook: Practical C/C++ Routines and Recipes for 
Error Detection and Correction 
Disk Included 


C. Britton Rorabaugh 


Hard ISBN 0-07-911720-1 1996 
251p. 71 Illus. 7 3/8 x 9 1/4 
$55.00 


xx Description ** 


At last, the complexities of error coding are made simple If you 
don't happen to be an abstract mathematician, it's all too easy to 
get lost in the maze of error correction coding thats is a crucial 
component of any signal processing or communications system. Now 
this first-of-it-kind, non-theoretical guide clearly explains the 
often complex error coding process. You'll find complete 
step-by-step instructions on how to: Select the most appropriate 
code for your particular application; Design the corresponding 
coders and decoders; Implement many of the most well-known and 
frequently used codes for error correction. Plus, you'll have 
access to ready-to-use C and C++ programs for generating hundreds 
of codes for error detection and correction on the accompanying 
disk. The book's exceptionally clear descriptions of each code are 
reinformed by an array of worked-out examples and a brief review 
of only the necessary math where applicable. There has never been 
a more illuminating or practical treatment of this always 
challenging and occasionally perplexing area. 


xx Audience xx 


Electronics, electrical, communications, and computer engineers 
designing all types of communications and signal processing 
equipment. 


*xx Contents xx 


Strategic Issues. Mathematical Tools for Coding. Block and Cyclic 
Codes. BCH and Reed-Solomon Codes. Encoders and Decoders. 
Convolutional Codes. Viterbi Decoding. Sequential Decoding. 


From dibene@VNET.IBM.COM Mon Jul 22 10:40:12 1996 

Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAAQ8341 for <hfsig@tapr.org>; Mon, 22 Jul 1996 
10:40:08 -0500 (CDT) 

Message-Id: <199607221540.KAA08341@tapr.org> 

Received: from ROMVMNIC by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2505; 


Mon, 22 Jul 96 11:40:00 EDT 
Date: Mon, 22 Jul 96 17:22:14 EDT 
From: dibene@VNET.IBM.COM (Alberto di Bene) 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1321] Re: FECC Chipsets 
Reply-To: dibene@VNET.IBM.COM 
Organization: IBM Semea S.p.A. 
News-Software: UReply 3.1 


In a previous message, Phil Karn wrote: 
Picard 3 snip ..... 


DF eile dasha Bi Sewedltestontie fol. I've done this for a FFT (specifically a radix 4 FFT 
> butterfly) and for a FIR. 


How about sharing a code snippet with hfsig, showing the butterfly 
and the FIR ? The wheel has been reinvented so many times, let's 
avoid one more reinvention... :-) 


Thanks in any case, 


Alberto di Bene, I2PHD dibene@vnet.ibm.com i2phd@amsat.org 


From karn@qualcomm.com Mon Jul 22 19:34:50 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id TAAQ0111 for <hfsig@tapr.org>; Mon, 22 Jul 1996 
19:34:47 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
RAAQ5156; Mon, 22 Jul 1996 17:34:15 -0700 (PDT) 

Date: Mon, 22 Jul 1996 17:34:15 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607230034.RAAQ5156@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <Pine.LNX.3.91.960719084458 .29452A-100000@bacchus.uet.e-technik.th- 
darmstadt.de> (message from Alexander Kurpiers on Fri, 19 Jul 1996 02:02:11 -0500 
(CDT) ) 

Subject: Re: [HFSIG:1312] Re: Are the new amateur datacomms modulations and 
protocols 


>I was talking to the developers of Pactor II the other week and they are 
>not willing to make the Pactor II specs available freely. I really don't 
>know any reason for this, but it is their decision. This means - at least 
>for German amateurs - that it could be illegal to use Pactor II. 


This policy (along with the similar proprietary attitudes of the companies 
making Clover and G-TOR) gives us an opportunity to create a new and open 
modulation and coding format more in the cooperative spirit of ham radio. 
And I believe it could easily outperform these proprietary schemes as well. 


Phil 


From karn@qualcomm.com Mon Jul 22 20:09:22 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id UAAQ1940 for <hfsig@tapr.org>; Mon, 22 Jul 1996 
20:09:20 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
SAAQ5265; Mon, 22 Jul 1996 18:08:48 -0700 (PDT) 

Date: Mon, 22 Jul 1996 18:08:48 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607230108.SAA0Q5265@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199607191650.JAA22300@ravel.n2.net> (k6sti@n2.net) 

Subject: Re: [HFSIG:1315] Re: Alexander wrote.. 


>But you didn't expend the resources to develop the algorithm. SCS tells me 
>they spent a very long time researching and testing the protocol. When you 
>do that, you can't afford to give the final result away. I'd love to 
>implement Pactor II myself, but I can understand why licenses aren't being 
>offered cheap. 


Keeping the protocol proprietary isn't necessarily going to pay back 
their development costs either. The computer and communications 
industry has a long history of proprietary technologies being quickly 
displaced by more open, standard systems. Anybody here still use a 
Telebit Trailblazer modem in PEP mode? 


More enlightened companies are content to have part of something 
rather than 100% of nothing. 


Phil 


From karn@qualcomm.com Mon Jul 22 20:27:48 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id UAAQ2640 for <hfsig@tapr.org>; Mon, 22 Jul 1996 
20:27:46 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
SAA05321; Mon, 22 Jul 1996 18:27:14 -0700 (PDT) 

Date: Mon, 22 Jul 1996 18:27:14 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607230127 .SAAQ5321@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199607192202.RAA19211@tapr.org> (message from Greg Jones on Fri, 19 
Jul 1996 17:03:53 -0500 (CDT)) 

Subject: Re: [HFSIG:1319] Re: Are the new amateur datacomms modulations and 
protocols 


>The ARRL has a publication that discusses the Clover, Pactor and GTOR. 
>These were presented at the 13th DCC I believe -- which was when the FCC 


>made the statement about publishing a standard to make it legal 


These papers discuss the general approaches used in each scheme, but they 


are by no means complete enough to write a compatible modem. So I certainly 
wouldn't call them "standards" or "specifications". 


Phil 


From JSANFORD@INFI.NET Mon Jul 22 20:32:12 1996 

Received: from mh004.infi.net (mailhost.infi.net [205.219.238.95]) by tapr.org 

(8.7.5/8.7.3/1.9) with ESMTP id UAAQ2749 for <hfsig@tapr.org>; Mon, 22 Jul 1996 

20:32:09 -0500 (CDT) 

Received: from pal4dsp6.orf.infi.net by mhO004.infi.net with SMTP 
(Infinet-S-3.3) id VAAO09766; Mon, 22 Jul 1996 21:32:09 -0400 (EDT) 

Message-Id: <1.5.4.16.19960723013230.0a07edd8@infi.net> 

X-Sender: jsanford@infi.net 

X-Mailer: Windows Eudora Light Version 1.5.4 (16) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Mon, 22 Jul 1996 21:32:30 -0400 

To: hfsig@tapr.org 

From: Jim Sanford <JSANFORD@INFI.NET> 

Subject: Re: [HFSIG:1324] Re: Are the new amateur datacomms modulations 

and protocols 


At 07:51 PM 7/22/96 -0500, you wrote: 

>>I was talking to the developers of Pactor II the other week and they are 
>>not willing to make the Pactor II specs available freely. I really don't 
>>know any reason for this, but it is their decision. This means - at least 
>>for German amateurs - that it could be illegal to use Pactor II. 

> 

>This policy (along with the similar proprietary attitudes of the companies 
>making Clover and G-TOR) gives us an opportunity to create a new and open 
>modulation and coding format more in the cooperative spirit of ham radio. 
>And I believe it could easily outperform these proprietary schemes as well. 
> 

>Phil 

> 


Outperform, outsell, obsolete them! 


(Especially the guys who use paying hams to test [at a high price] stuff they 
want to sell to the military!) 


73, Jim 
wb4gcs@amsat.org 


From wd5ivd@tapr.org Mon Jul 22 20:48:17 1996 

Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id UAA03433 for 
hfsig@tapr.org; Mon, 22 Jul 1996 20:48:16 -0500 (CDT) 

From: Greg Jones <wd5ivd@tapr.org> 

Message-Id: <199607230148.UAA03433@tapr.org> 

Subject: Re: [HFSIG:1326] Re: Are the new amateur datacomms modulations and 
protocols 

To: hfsig@tapr.org 


Date: Mon, 22 Jul 1996 20:48:15 -0500 (CDT) 

In-Reply-To: <199607230127.SAA05321@servo.qualcomm.com> from "Phil Karn" at Jul 
22, 96 08:29:44 pm 

X-Mailer: ELM [version 2.4 PL25] 

Content-Type: text 


I agree Phil. 


The issue was that these where what the FCC termed as being enough to allow 
legal operations under the unspecified digital modes area. 


Was not what the FCC agreed to the position that Paul Rinaldo and the Future 
Systems Committee work towards ? 


But as you point out -- these were not technical specifications. 


There is nothing keep this group or amateur radio as a whole from developing 
a standard that is more open and works better than current systems. 


Greg 

> 

> >The ARRL has a publication that discusses the Clover, Pactor and GTOR. 

> >These were presented at the 13th DCC I believe -- which was when the FCC 
> >made the statement about publishing a standard to make it legal 

> 

> These papers discuss the general approaches used in each scheme, but they 
> are by no means complete enough to write a compatible modem. So I certainly 
> wouldn't call them "standards" or "specifications". 

> 

> Phil 

> 

> 


From rs@ife.ee.ethz.ch Tue Jul 23 01:17:59 1996 

Received: from ife.ee.ethz.ch (ife-ifel.ee.ethz.ch [129.132.25.65]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id BAA18968 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
01:17:57 -0500 (CDT) 

Received: from gillespie.ee.ethz.ch (rs@gillespie.ee.ethz.ch [129.132.25.135]) by 
ife.ee.ethz.ch (8.7.5/8.7.5) with SMTP id IAA10855 for <hfsig@tapr.org>; Tue, 23 
Jul 1996 08:17:53 +0200 (MET DST) 

From: Rolf Sommerhalder <rs@ife.ee.ethz.ch> 

Received: by gillespie.ee.ethz.ch (8.6.11) id IAA21869; Tue, 23 Jul 1996 08:17:52 
+0200 

Message-Id: <199607230617.IAA21869@gillespie.ee.ethz.ch> 

Subject: Re: [HFSIG:1327] Re: Are the new amateur datacomms modulations 

To: hfsig@tapr.org 

Date: Tue, 23 Jul 1996 08:17:52 +0200 (MET DST) 

In-Reply-To: <1.5.4.16.19960723013230.0a07edd8@infi.net> from Jim Sanford at “Jul 
22, 96 08:47:51 pm" 

MIME-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 


Outperform, outsell, obsolete them! 


(Especially the guys who use paying hams to test [at a high price] stuff they 
want to sell to the military!) 


> >>I was talking to the developers of Pactor II the other week and they are 
> >>not willing to make the Pactor II specs available freely. I really don't 
> >>know any reason for this, but it is their decision. This means - at least 
> >>for German amateurs - that it could be illegal to use Pactor II. 

>> 

> >This policy (along with the similar proprietary attitudes of the companies 
> >making Clover and G-TOR) gives us an opportunity to create a new and open 
> >modulation and coding format more in the cooperative spirit of ham radio. 
> >And I believe it could easily outperform these proprietary schemes as well. 
>> 

> >Phil 

>> 

> 

> 

> 

> 

> 

> 


Unfortunately, it is even worse than selling just to the military: they sell / 
trying to sell it to the humanitarian aid community (Red Crosses/Crescents, 
United Nations agencies, non- and government organisations) - and at much 
higher prices. Though the problems is, that there are currently no decent 
alternatives really, besides SITOR/AMTOR or maybe GTOR/Pactor-1. 


Rolf, HB9CWP 


From karn@qualcomm.com Tue Jul 23 04:24:28 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id EAA23003 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
04:24:26 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
CAAQ6324; Tue, 23 Jul 1996 02:23:53 -0700 (PDT) 

Date: Tue, 23 Jul 1996 02:23:53 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607230923.CAAQ6324@servo.qualcomm. com> 

To: dibene@vnet.ibm.com 

CC: hfsig@tapr.org 

In-reply-to: <199607221540.KAA08341@tapr.org> (dibene@vnet.ibm.com) 

Subject: Re: [HFSIG:1323] Re: FECC Chipsets 


> How about sharing a code snippet with hfsig, showing the butterfly 
> and the FIR ? The wheel has been reinvented so many times, let's 

> avoid one more reinvention... :-) 

Okay, I've put the FIR filter on my web page: 


http://www. qualcomm.com/people/pkarn/ham. html 


I have to clean up and package the FFT code. When I do, I'll add it to the 
same page. 


Phil 


From karn@qualcomm.com Tue Jul 23 04:52:41 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id EAA23603 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
04:52:39 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
CAAQ6370; Tue, 23 Jul 1996 02:52:07 -0700 (PDT) 

Date: Tue, 23 Jul 1996 02:52:07 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607230952.CAAQ6370@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199607230148 .UAAQ03433@tapr.org> (message from Greg Jones on Mon, 22 
Jul 1996 21:05:58 -0@500 (CDT)) 

Subject: Re: [HFSIG:1328] Re: Are the new amateur datacomms modulations and 
protocols 


>The issue was that these where what the FCC termed as being enough to allow 
>legal operations under the unspecified digital modes area. 


I suspect that all the FCC really cares about is that they can get a box 
to monitor the emission if they want to. That simply means it has to 
be commercially available, which they all are. 


Unfortunately, that does nothing to promote general appreciation and 
understanding of what goes on in these newer modulation schemes. And I 
find that deeply troubling, as it's very much against what I believe to be 
the amateur radio spirit. 


Phil 


From karn@qualcomm.com Tue Jul 23 05:46:59 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id FAA24648 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
05:46:57 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
DAAOQ6525; Tue, 23 Jul 1996 03:46:26 -0700 (PDT) 

Date: Tue, 23 Jul 1996 03:46:26 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607231046.DAA06525@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199607181526.IAAQ4851@PEAK.ORG> (forrerj@peak.org) 

Subject: Re: [HFSIG:1309] Re: Q QPSK or not Q QPSK ? 


>I'm not sure Pactor II falls in this category. As far as I know and the way 
>I'm implementing their protocol, is that its simply two parallel DQPSK 
>channels 


You may be right -- I know relatively little about Pactor beyond what I 
read in some flyers I picked up at Dayton, and as we know they aren't 


publishing full specs. 


>This is quite interesting that you compare it to a form of frequency chirping. 


>When one take an OFDM ensamble for example, and then adjust phases for 
>minimal crest factor with some method like for example, Newman sequences, it 
>produces a time-domain pulse that has striking resemblances to an up-chirp 
>with a nearly flat amplitude. 


So what I can't understand is why people don't just go ahead and build 
systems that actually do chirp or spread, instead of building 
idiosyncratic approximations of same. 


I'm now more convinced than ever that the ideal HF modem would use 
M-ary FSK with frequency hopping. And of course the hopping could be 
turned off if desired. 


Phil 


From k6sti@n2.net Tue Jul 23 06:45:37 1996 

Received: from ravel.n2.net (ravel.n2.net [204.250.22.20]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id GAA26146 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
06:45:34 -0500 (CDT) 

Received: from ppp169.n2.net (ppp169.n2.net [204.250.22.169]) by ravel.n2.net 
(8.6.12/8.6.12) with SMTP id EAAQ6903 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
04:47:20 -0700 

Date: Tue, 23 Jul 1996 04:47:20 -0700 

Message-Id: <199607231147 .EAAQ6903@ravel .n2.net> 

X-Sender: k6sti@mail.n2.net 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: k6ésti@n2.net (Brian Beezley) 

Subject: HF Modem Bandwidth 


>BTW, one problem we'll have to face with the scheme I advocate is the 
>restrictive bandwidth limit on HF. I strongly advocate a wider signal 
>that would permit a considerable reduction in total signal power (10 dB 
>or more, according to the figures I've seen for the existing schemes) 
>and less QRM overall despite the extra bandwidth. 


10 dB is a lot--how much wider are you thinking, Phil? Tell me you don't 
want all of 20 meters! 


I think to go much beyond 500 Hz in the CW/DATA portion of the bands would 
add years to the introduction of a new protocol. The educational effort 
required would be enormous. I think you could probably get the FCC to go 
along--it's the general ham population that would react very negatively to 
any kind of wideband proposal. At the minimum I think wideband signals 
would have to be restricted to a tight subband. Still, I'm sure it would 
take years to get authorized. I don't have the patience. 


You might be able to slip it into the SSB part of the band. I once operated 


HF fax with a couple buddies using Western Union Deskfax machines before 
this mode was legal on HF. We built little FM modulators, operated near the 
SSTV frequencies, and on the air always referred to it as "SSTV." If you 
came up with a digital picture-coding scheme that happened to have a great 
HF modem built into it and was less than 3 kHz wide, I think you could use 
it today on the air without any problem. Just call it Scottie 17 or 
something. One day you accidentally send a text file instead of a picture 
file and you're on your way. Although this backdoor approach might actually 
work, it's a little too sneaky for my taste. 


So how wide? And what exactly is the scheme you advocate? 


73--Brian, K6STI 
k6sti@n2.net 


From rick@itron-ca.com Tue Jul 23 11:35:13 1996 

Received: from itron-ca.com (gate.itron-ca.com [204.30.20.2]) by tapr.org 

(8.7.5/8.7.3/1.9) with SMTP id LAAQ6865 for <hfsig@tapr.org>; Tue, 23 Jul 1996 

11:35:10 -0500 (CDT) 

Received: (from audit@localhost) by itron-ca.com (8.6.9/8.6.9) id JAA19450 for 

<hfsig@tapr.org>; Tue, 23 Jul 1996 09:35:07 -0700 

Received: from unknown(204.30.20.214) by gate.itron-ca.com via smap (V1.3mjr) 
id smaQ19440; Tue Jul 23 09:34:24 1996 

Date: Tue, 23 Jul 96 09:36:00 

From: Rick Booth <rick@itron-ca.com> 

Subject: RE: [HFSIG:1333] HF Modem Bandwidth 

To: hfsig@tapr.org 

X-PRIORITY: 3 (Normal) 

X-Mailer: Chameleon 5.0, TCP/IP for Windows, NetManage Inc. 

Message-ID: <Chameleon.838139912.rick@rickb.itron-ca.com> 

MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Brian, 

My guess is the biggest stumbling block to wideband com at HF is the base of 
transceivers 

already in place among the ham world...this puts the upper limit at about 2.4 KHz. 
How many 

hams will hack a 2 grand plus radio to diddle with wider filters? 

Rick 


Rick Booth 
'95 900SS SP 
E-mail: rick@itron-ca.com 


From ADMINISTRATOR@MAF.Org Tue Jul 23 12:55:14 1996 
Received: from daniel.maf.org (daniel.maf.org [204.31.147.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id MAA10319 for <hfsig@tapr.org>; Tue, 23 Jul 1996 


12:55:11 -0500 (CDT) 
Received: from gabriel.maf.org (gabriel.maf.org [204.31.147.3]) by daniel.maf.org 
(8.7.5/96060501) with SMTP id KAAQ2067 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
10:53:45 -0700 (PDT) 
Received: from ccMail by gabriel.maf.org (SMTPLINK V2.11 PreRelease 4) 
id AA838144057; Tue, 23 Jul 96 16:10:12 UTC 
Date: Tue, 23 Jul 96 16:10:12 UTC 
From: ADMINISTRATORG@MAF . Org 
Message-Id: <9606238381.AA838144057@gabriel.maf.org> 
To: hfsig@tapr.org 
Subject: Message not deliverable 


In a previous message, Phil Karn wrote: 
Sick snip ..... 


DS) cevee awe el stelo Sa fe I've done this for a FFT (specifically a radix 4 FFT 
> butterfly) and for a FIR. 


How about sharing a code snippet with hfsig, showing the butterfly 
and the FIR ? The wheel has been reinvented so many times, let's 
avoid one more reinvention... :-) 


Thanks in any case, 


Alberto di Bene, I2PHD dibene@vnet.ibm.com i2phd@amsat.org 


From ADMINISTRATOR@MAF.Org Tue Jul 23 12:56:12 1996 
Received: from daniel.maf.org (daniel.maf.org [204.31.147.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id MAA10437 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
12:56:08 -0500 (CDT) 
Received: from gabriel.maf.org (gabriel.maf.org [204.31.147.3]) by daniel.maf.org 
(8.7.5/96060501) with SMTP id KAAQ2192 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
10:54:37 -0700 (PDT) 
Received: from ccMail by gabriel.maf.org (SMTPLINK V2.11 PreRelease 4) 

id AA838144149; Tue, 23 Jul 96 16:17:13 UTC 
Date: Tue, 23 Jul 96 16:17:13 UTC 
From: ADMINISTRATORG@MAF . Org 
Message-Id: <9606238381.AA838144149@gabriel.maf.org> 
To: hfsig@tapr.org 
Subject: Message not deliverable 


At 07:51 PM 7/22/96 -0500, you wrote: 

>>I was talking to the developers of Pactor II the other week and they are 
>>not willing to make the Pactor II specs available freely. I really don't 
>>know any reason for this, but it is their decision. This means - at least 
>>for German amateurs - that it could be illegal to use Pactor II. 

> 


>This policy (along with the similar proprietary attitudes of the companies 
>making Clover and G-TOR) gives us an opportunity to create a new and open 
>modulation and coding format more in the cooperative spirit of ham radio. 
>And I believe it could easily outperform these proprietary schemes as well. 
> 

>Phil 

> 


Outperform, outsell, obsolete them! 


(Especially the guys who use paying hams to test [at a high price] stuff they 
want to sell to the military!) 


73, Jim 
wb4gcs@amsat.org 


From ADMINISTRATOR@MAF.Org Tue Jul 23 12:56:14 1996 
Received: from daniel.maf.org (daniel.maf.org [204.31.147.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id MAA10440 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
12:56:11 -0500 (CDT) 
Received: from gabriel.maf.org (gabriel.maf.org [204.31.147.3]) by daniel.maf.org 
(8.7.5/96060501) with SMTP id KAAQ2173 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
10:54:31 -0700 (PDT) 
Received: from ccMail by gabriel.maf.org (SMTPLINK V2.11 PreRelease 4) 

id AA838144142; Tue, 23 Jul 96 16:16:16 UTC 
Date: Tue, 23 Jul 96 16:16:16 UTC 
From: ADMINISTRATORG@MAF . Org 
Message-Id: <9606238381.AA838144142@gabriel.maf.org> 
To: hfsig@tapr.org 
Subject: Message not deliverable 


>But you didn't expend the resources to develop the algorithm. SCS tells me 
>they spent a very long time researching and testing the protocol. When you 
>do that, you can't afford to give the final result away. I'd love to 
>implement Pactor II myself, but I can understand why licenses aren't being 
>offered cheap. 


Keeping the protocol proprietary isn't necessarily going to pay back 
their development costs either. The computer and communications 
industry has a long history of proprietary technologies being quickly 
displaced by more open, standard systems. Anybody here still use a 
Telebit Trailblazer modem in PEP mode? 


More enlightened companies are content to have part of something 
rather than 100% of nothing. 


Phil 


From ADMINISTRATOR@MAF.Org Tue Jul 23 12:56:20 1996 
Received: from daniel.maf.org (daniel.maf.org [204.31.147.2]) by tapr.org 


(8.7.5/8.7.3/1.9) with ESMTP id MAA10477 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
12:56:16 -0500 (CDT) 
Received: from gabriel.maf.org (gabriel.maf.org [204.31.147.3]) by daniel.maf.org 
(8.7.5/96060501) with SMTP id KAAQ2195 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
10:54:43 -0700 (PDT) 
Received: from ccMail by gabriel.maf.org (SMTPLINK V2.11 PreRelease 4) 
id AA838144157; Tue, 23 Jul 96 16:18:59 UTC 
Date: Tue, 23 Jul 96 16:18:59 UTC 
From: ADMINISTRATORG@MAF . Org 
Message-Id: <9606238381.AA838144157@gabriel.maf.org> 
To: hfsig@tapr.org 
Subject: Message not deliverable 


>>I was talking to the developers of Pactor II the other week and they are 
>>not willing to make the Pactor II specs available freely. I really don't 
>>know any reason for this, but it is their decision. This means - at least 
>>for German amateurs - that it could be illegal to use Pactor II. 

> 

>This policy (along with the similar proprietary attitudes of the companies 
>making Clover and G-TOR) gives us an opportunity to create a new and open 
>modulation and coding format more in the cooperative spirit of ham radio. 
>And I believe it could easily outperform these proprietary schemes as well. 
> 

>Phil 

> 


Outperform, outsell, obsolete them! 


(Especially the guys who use paying hams to test [at a high price] stuff they 
want to sell to the military!) 


VVVVVV VV VV VV VV VV VM 


Unfortunately, it is even worse than selling just to the military: they sell / 
trying to sell it to the humanitarian aid community (Red Crosses/Crescents, 
United Nations agencies, non- and government organisations) - and at much 
higher prices. Though the problems is, that there are currently no decent 
alternatives really, besides SITOR/AMTOR or maybe GTOR/Pactor-1. 


Rolf, HB9CWP 


From ADMINISTRATOR@MAF.Org Tue Jul 23 12:56:22 1996 
Received: from daniel.maf.org (daniel.maf.org [204.31.147.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id MAA10478 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
12:56:17 -0500 (CDT) 
Received: from gabriel.maf.org (gabriel.maf.org [204.31.147.3]) by daniel.maf.org 
(8.7.5/96060501) with SMTP id KAAQ2194 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
10:54:41 -0700 (PDT) 
Received: from ccMail by gabriel.maf.org (SMTPLINK V2.11 PreRelease 4) 

id AA838144153; Tue, 23 Jul 96 16:18:37 UTC 
Date: Tue, 23 Jul 96 16:18:37 UTC 
From: ADMINISTRATORG@MAF . Org 
Message-Id: <9606238381.AA838144153@gabriel.maf.org> 


To: hfsig@tapr.org 
Subject: Message not deliverable 


I agree Phil. 


The issue was that these where what the FCC termed as being enough to allow 
legal operations under the unspecified digital modes area. 


Was not what the FCC agreed to the position that Paul Rinaldo and the Future 
Systems Committee work towards ? 


But as you point out -- these were not technical specifications. 


There is nothing keep this group or amateur radio as a whole from developing 
a standard that is more open and works better than current systems. 


Greg 

> 

> >The ARRL has a publication that discusses the Clover, Pactor and GTOR. 

> >These were presented at the 13th DCC I believe -- which was when the FCC 
> >made the statement about publishing a standard to make it legal 

> 

> These papers discuss the general approaches used in each scheme, but they 
> are by no means complete enough to write a compatible modem. So I certainly 
> wouldn't call them "standards" or "specifications". 

> 

> Phil 

> 

> 


From ADMINISTRATOR@MAF.Org Tue Jul 23 12:56:26 1996 
Received: from daniel.maf.org (daniel.maf.org [204.31.147.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id MAA10488 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
12:56:20 -0500 (CDT) 
Received: from gabriel.maf.org (gabriel.maf.org [204.31.147.3]) by daniel.maf.org 
(8.7.5/96060501) with SMTP id KAAQ2172 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
10:54:31 -0700 (PDT) 
Received: from ccMail by gabriel.maf.org (SMTPLINK V2.11 PreRelease 4) 

id AA838144139; Tue, 23 Jul 96 16:15:47 UTC 
Date: Tue, 23 Jul 96 16:15:47 UTC 
From: ADMINISTRATORG@MAF . Org 
Message-Id: <9606238381.AA838144139@gabriel.maf.org> 
To: hfsig@tapr.org 
Subject: Message not deliverable 


>I was talking to the developers of Pactor II the other week and they are 
>not willing to make the Pactor II specs available freely. I really don't 
>know any reason for this, but it is their decision. This means - at least 
>for German amateurs - that it could be illegal to use Pactor II. 


This policy (along with the similar proprietary attitudes of the companies 


making Clover and G-TOR) gives us an opportunity to create a new and open 
modulation and coding format more in the cooperative spirit of ham radio. 
And I believe it could easily outperform these proprietary schemes as well. 


Phil 


From ADMINISTRATOR@MAF.Org Tue Jul 23 12:56:26 1996 
Received: from daniel.maf.org (daniel.maf.org [204.31.147.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id MAA10495 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
12:56:20 -0500 (CDT) 
Received: from gabriel.maf.org (gabriel.maf.org [204.31.147.3]) by daniel.maf.org 
(8.7.5/96060501) with SMTP id KAAQ2174 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
10:54:32 -0700 (PDT) 
Received: from ccMail by gabriel.maf.org (SMTPLINK V2.11 PreRelease 4) 

id AA838144146; Tue, 23 Jul 96 16:16:51 UTC 
Date: Tue, 23 Jul 96 16:16:51 UTC 
From: ADMINISTRATORG@MAF . Org 
Message-Id: <9606238381.AA838144146@gabriel.maf.org> 
To: hfsig@tapr.org 
Subject: Message not deliverable 


>The ARRL has a publication that discusses the Clover, Pactor and GTOR. 
>These were presented at the 13th DCC I believe -- which was when the FCC 
>made the statement about publishing a standard to make it legal 


These papers discuss the general approaches used in each scheme, but they 
are by no means complete enough to write a compatible modem. So I certainly 
wouldn't call them "standards" or "specifications". 


Phil 


From ADMINISTRATOR@MAF.Org Tue Jul 23 12:57:00 1996 
Received: from daniel.maf.org (daniel.maf.org [204.31.147.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id MAA10548 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
12:56:58 -0500 (CDT) 
Received: from gabriel.maf.org (gabriel.maf.org [204.31.147.3]) by daniel.maf.org 
(8.7.5/96060501) with SMTP id KAAQ2264 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
10:55:34 -0700 (PDT) 
Received: from ccMail by gabriel.maf.org (SMTPLINK V2.11 PreRelease 4) 

id AA838144168; Tue, 23 Jul 96 16:19:43 UTC 
Date: Tue, 23 Jul 96 16:19:43 UTC 
From: ADMINISTRATORG@MAF . Org 
Message-Id: <9606238381.AA838144168@gabriel.maf.org> 
To: hfsig@tapr.org 
Subject: Message not deliverable 


>The issue was that these where what the FCC termed as being enough to allow 
>legal operations under the unspecified digital modes area. 


I suspect that all the FCC really cares about is that they can get a box 
to monitor the emission if they want to. That simply means it has to 


be commercially available, which they all are. 


Unfortunately, that does nothing to promote general appreciation and 
understanding of what goes on in these newer modulation schemes. And I 
find that deeply troubling, as it's very much against what I believe to be 
the amateur radio spirit. 


Phil 


From ADMINISTRATOR@MAF.Org Tue Jul 23 12:57:01 1996 
Received: from daniel.maf.org (daniel.maf.org [204.31.147.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id MAA10550 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
12:56:59 -0500 (CDT) 
Received: from gabriel.maf.org (gabriel.maf.org [204.31.147.3]) by daniel.maf.org 
(8.7.5/96060501) with SMTP id KAAQ2263 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
10:55:33 -0700 (PDT) 
Received: from ccMail by gabriel.maf.org (SMTPLINK V2.11 PreRelease 4) 

id AA838144164; Tue, 23 Jul 96 16:19:21 UTC 
Date: Tue, 23 Jul 96 16:19:21 UTC 
From: ADMINISTRATORG@MAF . Org 
Message-Id: <9606238381.AA838144164@gabriel.maf.org> 
To: hfsig@tapr.org 


Subject: Message not deliverable 


> How about sharing a code snippet with hfsig, showing the butterfly 
> and the FIR ? The wheel has been reinvented so many times, let's 
> avoid one more reinvention... :-) 


Okay, I've put the FIR filter on my web page: 
http: //www.qualcomm.com/people/pkarn/ham. html 


I have to clean up and package the FFT code. When I do, I'll add it to the 
same page. 


Phil 


From karn@qualcomm.com Tue Jul 23 13:01:53 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id NAA10665 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
13:01:51 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
LAA14798; Tue, 23 Jul 1996 11:01:12 -0700 (PDT) 

Date: Tue, 23 Jul 1996 11:01:12 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607231801.LAA14798@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <Chameleon.838139912.rick@rickb.itron-ca.com> (message from Rick 
Booth on Tue, 23 Jul 1996 11:49:00 -0500 (CDT)) 

Subject: Re: [HFSIG:1334] RE: HF Modem Bandwidth 


>My guess is the biggest stumbling block to wideband com at HF is the 
>base of transceivers already in place among the ham world...this puts 
>the upper limit at about 2.4 KHz. 


Well, mostly yes. But you can actually do a lot in 2.4 KHz, at least compared 
to 500 Hz. And there's the possibility of frequency hopping the whole thing, 
depending on the speed of the synthesizer and the computer control interface. 


But I agree, wider filters are ultimately necessary. It may be 
possible to modify many radios to provide them, although they are 
really not widely (!) available. At Dayton I asked the Fox-Tango 
people and they said they had never gotten a request for a xwider* 
filter before... 


Phil 


From k5yfw@www.kelly-afb.org Tue Jul 23 17:59:43 1996 

Received: from www.kelly-afb.org (www.kelly-afb.org [204.214.204.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id RAA27315 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
17:59:40 -0500 (CDT) 

Received: (from k5yfw@localhost) by www.kelly-afb.org (8.7.1/8.7.1) id SAA06286 
for hfsig@tapr.org; Tue, 23 Jul 1996 18:00:13 -0500 (CDT) 

From: Walt DuBose - K5YFW <k5yfw@www.kelly-afb.org> 

Message-Id: <199607232300.SAA06286@www.kelly-afb.org> 

Subject: Re: [HFSIG:1342] Message not deliverable 

To: hfsig@tapr.org 

Date: Tue, 23 Jul 1996 18:00:13 -0500 (CDT) 

In-Reply-To: <9606238381.AA838144168@gabriel.maf.org> from "“ADMINISTRATOR@maf. org" 
at Jul 23, 96 01:49:33 pm 

Reply-To: k5yfw@www.kelly-afb.org 

X-Mailer: ELM [version 2.4 PL24] 

Content-Type: text 


Phil, 


I've had conversations with some FCC Field Types and get the same feeling... 
if they can obtain a "box" to monitor the "data", they are happy. 


In a previous message you referenced RX bandwidth...this worrys me 
because I feel that your/our effort shold be originally to work within 
the bandpass of the xceivers on the air today with a built-in design to 
go with wider bandwidths as xceivers (RF equipment) becomes available. 


Your comments on PACTOR, G-tor and Clover are right on line. You 
(plural) /we should build a better protocol and implement it on a DSP 
sound card/one of the /dsp platforms or the TAPR platform whichever makes 
the most sense for the protocol. 


Walt on vacation in ID...hello Johan...was near your QTH yesterday 
afternoon...Ok...about 150 miles away. 


73 all. 


> 

> >The issue was that these where what the FCC termed as being enough to allow 
> >legal operations under the unspecified digital modes area. 

> 

> I suspect that all the FCC really cares about is that they can get a box 

> to monitor the emission if they want to. That simply means it has to 

> be commercially available, which they all are. 

> 

> Unfortunately, that does nothing to promote general appreciation and 

> understanding of what goes on in these newer modulation schemes. And I 

> find that deeply troubling, as it's very much against what I believe to be 
> the amateur radio spirit. 

> 

> Phil 

> 


Vv 


| The MicroSoft operating system didn't get as bad as it is overnight, | 
| it has taken over 10 years of careful, calculated development. | 


| The greatest dangers to liberty 
Walt DuBose - K5YFW | lurk in insidious encroachment 
E-Mail k5yfw@www.kelly-afb.org | by men of zeal, well-meaning 
Business Telephone: (210)925-6081 | but without understanding. 
Home Telephone: (210)696-3196 | | 
| - Justice Louis D. Brandeis | 


From karn@qualcomm.com Tue Jul 23 21:46:36 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id VAAQ8019 for <hfsig@tapr.org>; Tue, 23 Jul 1996 
21:46:32 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
TAA16616; Tue, 23 Jul 1996 19:46:00 -0700 (PDT) 

Date: Tue, 23 Jul 1996 19:46:00 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607240246.TAA16616@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199607232300.SAAQ06286@www.kelly-afb.org> (message from Walt DuBose - 
K5YFW on Tue, 23 Jul 1996 18:11:44 -0500 (CDT)) 

Subject: Re: [HFSIG:1345] Re: Message not deliverable 


>In a previous message you referenced RX bandwidth...this worrys me 
>because I feel that your/our effort shold be originally to work within 
>the bandpass of the xceivers on the air today with a built-in design to 
>go with wider bandwidths as xceivers (RF equipment) becomes available. 


Well, I agree that at first we should strive for something that fits 
in a SSB bandwidth, just to be able to use existing transceivers and 
filters. So the problem is mainly with the FCC rules, insofar as they 
limit us to 300 baud and/or 1Khz "mark/space shift" (not sure how that 
applies to M-ary FSK). And only certain codes seem to be allowed. 


And I also agree that our problems are more likely to be with the ham 
population, not the FCC. That's certainly the case so far with the 
proposed spread spectrum rule changes -- and these changes are really all 
part of the same thing. 


Phil 


From forrerj@peak.org Wed Jul 24 00:32:36 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id AAA18074 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
00:32:26 -0500 (CDT) 

Received: from p04.t0.monrotel.com (p04.tO.monrotel.com [198.68.25.37]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id WAAQ7907 for <hfsig@tapr.org>; Tue, 23 Jul 
1996 22:32:33 -0700 

Message-Id: <199607240532.WAAQ7907@PEAK.ORG> 

X-Sender: forrerj@peak.org (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Tue, 23 Jul 1996 22:19:21 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: HF bandwidth 


Phil, 


I changed the topic to get everyone confused. 


>>In a previous message you referenced RX bandwidth...this worrys me 
>>because I feel that your/our effort shold be originally to work within 
>>the bandpass of the xceivers on the air today with a built-in design to 
>>go with wider bandwidths as xceivers (RF equipment) becomes available. 


Arn't we are getting closer to a new era of all-digital radios? That should 
perhaps allow us to customise bandwiths as needed. 


> 

>Well, I agree that at first we should strive for something that fits 
>in a SSB bandwidth, just to be able to use existing transceivers and 
>filters. 


I believe to do things in small steps and build confidence and enthuisiasm. 
It will take some convincing putting a new type of emission in a slot that 


has traditionally been dedicated for another purpose. I do, however, see no 
problem with the new OFDM, FDM schemes, or even your new scheme being 
introduced. At least the signals that that I have casually listened to, 
sounds pretty much like a regular 300 baud HF packet signal. I would'nt be 
surprised at all if folks would use their HF packet TNC's to try decode it. 


>So the problem is mainly with the FCC rules, insofar as they 
>limit us to 300 baud and/or 1Khz "mark/space shift" (not sure how that 
>applies to M-ary FSK). And only certain codes seem to be allowed. 


I thought that we posed that question to Paul Rinaldo at the last DCC. He 
and Chris Imley looked into the matter. I was imformed by Chris, at Paul's 
request, that they were sure that there was no problem using MFSK, i.e., the 
multitone modems (I agree that part 97 is little fuzzy on that one). I 
assume the 300 baud/1 kHz restrictions was taken into consideration. I do 
think we are at liberty to take that for granted now. If we behave ourselves 
and do a good job of using and promoting this technology, I can only hope 
that it would find general acceptance. 


> 

>And I also agree that our problems are more likely to be with the ham 
>population, not the FCC. That's certainly the case so far with the 
>proposed spread spectrum rule changes -- and these changes are really all 
>part of the same thing. 

> 

>Phil 

> 

> 


Your'e probably right about this - the fear of the unknown, or giving up 
some creature comforts. 


--Johan 


From k5yfw@www.kelly-afb.org Wed Jul 24 00:51:23 1996 

Received: from www.kelly-afb.org (www.kelly-afb.org [204.214.204.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id AAA18790 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
00:51:22 -0500 (CDT) 

Received: (from k5yfw@localhost) by www.kelly-afb.org (8.7.1/8.7.1) id AAAQ7490 
for hfsig@tapr.org; Wed, 24 Jul 1996 00:51:55 -0500 (CDT) 

From: Walt DuBose - K5YFW <k5yfw@www.kelly-afb.org> 

Message-Id: <199607240551.AAAQ7490@www.kelly-afb.org> 

Subject: Re: [HFSIG:1346] Re: Message not deliverable 

To: hfsig@tapr.org 

Date: Wed, 24 Jul 1996 00:51:54 -0500 (CDT) 

In-Reply-To: <199607240246.TAA16616@servo.qualcomm.com> from "Phil Karn" at Jul 
23, 96 10:01:48 pm 

Reply-To: k5yfw@www.kelly-afb.org 

X-Mailer: ELM [version 2.4 PL24] 

Content-Type: text 


Phil, 


You guys build the protocol and make it work and I'll use it and die 
trying to sell it to the ham community and get the FCC to let it be used. 
I work for the government and selling good ideas to government officials 
has been making me a living wage for 30+ years. I've only failed once and 
that was with the Air Force Aeromedical Evacuation System but my idea has 
now been taken up by the DEA, Navy, Marine Corp. and Coast Guard. 


Walt 


In your message you write: 

> 

> >In a previous message you referenced RX bandwidth...this worrys me 

> >because I feel that your/our effort shold be originally to work within 
> >the bandpass of the xceivers on the air today with a built-in design to 
> >go with wider bandwidths as xceivers (RF equipment) becomes available. 
> 

> Well, I agree that at first we should strive for something that fits 

> in a SSB bandwidth, just to be able to use existing transceivers and 

> filters. So the problem is mainly with the FCC rules, insofar as they 

> limit us to 300 baud and/or 1Khz "mark/space shift" (not sure how that 

> applies to M-ary FSK). And only certain codes seem to be allowed. 

> 

> And I also agree that our problems are more likely to be with the ham 

> population, not the FCC. That's certainly the case so far with the 

> proposed spread spectrum rule changes -- and these changes are really all 
> part of the same thing. 

> 

> Phil 

> 


| The MicroSoft operating system didn't get as bad as it is overnight, | 
| it has taken over 10 years of careful, calculated development. | 


| The greatest dangers to liberty 
Walt DuBose - K5YFW | lurk in insidious encroachment 
E-Mail k5yfw@www.kelly-afb.org | by men of zeal, well-meaning 
Business Telephone: (210)925-6081 | but without understanding. 
Home Telephone: (210)696-3196 | | 
| - Justice Louis D. Brandeis | 


From n4hy@ccr-p.ida.org Wed Jul 24 01:02:31 1996 
Received: from idacrd.ccr-p.ida.org (idacrd.ccr-p.ida.org [206.181.22.66]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id BAA18860 for <hfsig@tapr.org>; Wed, 24 


Jul 1996 01:02:28 -0500 (CDT) 

Received: from idacrd.ccr-p.ida.org (daemon@localhost) by idacrd.ccr-p.ida.org 
(8.7.2/8.7.2) with ESMTP id CAA01799 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
02:03:11 -0400 (EDT) 

Received: from ccr-p.ida.org (xida.ccr-p.ida.org [198.3.6.62]) by idacrd.ccr- 
p.ida.org (8.7.2/8.7.2) with SMTP id CAAQ1795 for <hfsig@tapr.org>; Wed, 24 Jul 
1996 02:03:10 -0400 (EDT) 

Received: from growler.ccr-p.ida.org (growler.ccr-p.ida.org [198.3.6.3]) by ccr- 
p.ida.org (8.6.12/8.6.12) with ESMTP id CAA07379 for <hfsig@tapr.org>; Wed, 24 Jul 
1996 02:02:06 -0400 

From: Bob McGwier <n4hy@ccr-p.ida.org> 

Received: (from n4hy@localhost) by growler.ccr-p.ida.org (8.7.5/8.7.3) id CAA15033 
for hfsig@tapr.org; Wed, 24 Jul 1996 02:02:03 -0400 (EDT) 

Date: Wed, 24 Jul 1996 02:02:03 -0400 (EDT) 

Message-Id: <199607240602.CAA15033@growler.ccr-p.ida.org> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1313] Alexander wrote.. 

In-reply-to: <slefb8e7.052@KIDD.CO.ZA> (message from Danie Brynard on Fri, 19 Jul 
1996 09:42:09 -0500 (CDT)) 


I am in possession of three articles about PACTOR II. It contains everything 
except the details of the interleaving algorithm and the fallback/upgrade 
algorithm. They are written by the PACTOR folks for publication. No, 

I am not willing to make a thousand copies for people. It was published in 
the Digital Digest I believe but I would have to look and I won't be able 

to for at least three weeks (when I begin unpacking at our new residence, 

we are moving a whole five blocks). Someone might check on this. 


Bob 


From forrerj@peak.org Wed Jul 24 01:21:43 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id BAA19368 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
01:18:16 -0500 (CDT) 

Received: from p03.tO0.monrotel.com (p03.tO.monrotel.com [198.68.25.36]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id XAA11860 for <hfsig@tapr.org>; Tue, 23 Jul 
1996 23:18:36 -0700 

Message-Id: <199607240618.XAA11860@PEAK.ORG> 

X-Sender: forrerj@peak.org (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Tue, 23 Jul 1996 23:05:25 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: How to define a new protocol 


Hi all, 
I am looking for suggestions on how to define a protocol. Shall I follow the 


way that the CCIR did theirs, i.e., a couple of state diagrams and notes? I 
found it to be comprehensive enough to build your own code implementation 


from it. 


Seem to remember some time ago, I read somewhere, of the exsistance of a 
formal language to do this kind of thing. As far as I remember it was a 
structured definition language where one could travel down a tree to unfold 
lower levels of more complex parts. But my memory is vague. 


Thanks, 


--Johan 


From karn@qualcomm.com Wed Jul 24 03:08:45 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id DAA22564 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
03:08:44 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
BAA17329; Wed, 24 Jul 1996 01:08:13 -0700 (PDT) 

Date: Wed, 24 Jul 1996 01:08:13 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607240808 .BAA17329@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199607240532.WAAQ7907@PEAK.ORG> (forrerj@peak.org) 

Subject: Re: [HFSIG:1347] Re: HF bandwidth 


>Arn't we are getting closer to a new era of all-digital radios? That should 
>perhaps allow us to customise bandwiths as needed. 


Well, they'll still have their limits. I want no limits. Or at least a 
radio with a fairly wide IF xand*x the ability to frequency hop reasonably fast. 


>I thought that we posed that question to Paul Rinaldo at the last DCC. He 
>and Chris Imley looked into the matter. I was imformed by Chris, at Paul's 
>request, that they were sure that there was no problem using MFSK, i.e., the 
>multitone modems (I agree that part 97 is little fuzzy on that one). I 
>assume the 300 baud/1 kHz restrictions was taken into consideration. I do 
>think we are at liberty to take that for granted now. If we behave ourselves 
>and do a good job of using and promoting this technology, I can only hope 
>that it would find general acceptance. 


But it's precisely those 300 baud/1 KHz restrictions that I want to eliminate. 
Eventually I want to spread over the whole band with frequency hopping, but 
to start I'd like to do MFSK over SSB bandwidths. 


Phil 


From karn@qualcomm.com Wed Jul 24 03:09:38 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id DAA22588 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
03:09:37 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 


BAA17345; Wed, 24 Jul 1996 01:09:06 -0700 (PDT) 

Date: Wed, 24 Jul 1996 01:09:06 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607240809.BAA17345@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199607240551.AAA07490@www.kelly-afb.org> (message from Walt DuBose - 
K5YFW on Wed, 24 Jul 1996 00:57:29 -0500 (CDT)) 

Subject: Re: [HFSIG:1348] Re: Message not deliverable 


>You guys build the protocol and make it work and I'll use it and die 
>trying to sell it to the ham community and get the FCC to let it be used. 


Okay, you're on. Don't underestimate the job you've taken on. Getting an 
STA for ourselves will be fairly easy. Getting the rules changed to permit 
general use will be the trick. 


Phil 


From chbrain@dircon.co.uk Wed Jul 24 03:31:16 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id DAA23121 for <hfsig@tapr.org>; Wed, 24 Jul 
1996 03:31:13 -0500 (CDT) 
Received: by felix.dircon.co.uk id AA28142 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Wed, 24 Jul 1996 09:31:03 +0100 
Message-Id: <199607240831.AA28142@felix.dircon.co.uk> 
Received: from gw2-132.pool.dircon.co.uk(194.112.35.132) by amnesiac via smap 
(V1.3) 
id sma028119; Wed Jul 24 09:30:41 1996 
X-Sender: chbrain@popmail.dircon.co.uk 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Wed, 24 Jul 1996 09:19:14 +0100 
To: hfsig@tapr.org 
From: chbrain@dircon.co.uk (Charles Brain) 
Subject: Re: [HFSIG:1350] How to define a new protocol 


>Hi all, 

> 

>I am looking for suggestions on how to define a protocol. Shall I follow the 
>way that the CCIR did theirs, i.e., a couple of state diagrams and notes? I 
>found it to be comprehensive enough to build your own code implementation 
>from it. 

> 

>Seem to remember some time ago, I read somewhere, of the exsistance of a 
>formal language to do this kind of thing. As far as I remember it was a 
>structured definition language where one could travel down a tree to unfold 
>lower levels of more complex parts. But my memory is vague. 

> 

> 

>Thanks, 

> 


>--Johan 
Hello Johan, 


As someone that has to implement protocols for a living I prefer either 

a comprehensive set of State Diagrams or better still SDL (Z.100 I think). 
There was a description of this in the 

ARRL 7th Computer Networking Conference. 


- Charles 


From seeler@upei.ca Wed Jul 24 04:06:38 1996 

Received: from venus.cs.upei.ca (venus.cs.upei.ca [137.149.1.20]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id EAA24297 for <hfsig@tapr.org>; Wed, 24 Jul 1996 

04:06:36 -0500 (CDT) 

Received: from atlas.cs.upei.ca (slip60.slip.upei.ca) 

by upei.ca (PMDF V5.0-5 #9415) id <Q1I7FVNP714WJ25QUK@upei.ca> for 
hfsig@tapr.org; Wed, 24 Jul 1996 06:06:35 -0300 (ADT) 

Date: Wed, 24 Jul 1996 06:06:25 -0003 

From: David Seeler <seeler@upei.ca> 

Subject: Re: [HFSIG:1349] Re: Alexander wrote.. 

To: hfsig@tapr.org 

Reply-to: Seeler@upei.ca 

Message-id: <OQ1I7FVNQWLK6J25QUK@upei.ca> 

X-Mailer: Pegasus Mail for Win32 (v2.42a) 

Content-transfer-encoding: 7BIT 

Priority: normal 

Comments: Authenticated sender is <seeler@mailer.cs.upei.ca> 


On 24 Jul 96 at 1:16, Bob McGwier wrote: 


I am in possession of three articles about PACTOR II. It contains everything 
except the details of the interleaving algorithm and the fallback/upgrade 
algorithm. They are written by the PACTOR folks for publication. No, 

I am not willing to make a thousand copies for people. It was published in 
the Digital Digest I believe but I would have to look and I won't be able 

to for at least three weeks (when I begin unpacking at our new residence, 

we are moving a whole five blocks). Someone might check on this. 


Bob 


VV VVVV VV VV WV 


Check out the PActor II home page: 


http: //www.scs-ptc.com/index8. html 


There is a number of articles about the methodology etc there - 
including a suggestion that AEA has purchased a license for PActor II 


> 
Best Regards, 
David Seeler, VY2DCS 


From karn@qualcomm.com Wed Jul 24 04:26:34 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id EAA24815 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
04:26:32 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
CAA17580; Wed, 24 Jul 1996 02:26:01 -0700 (PDT) 

Date: Wed, 24 Jul 1996 02:26:01 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607240926.CAA17580@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199607240618.XAA11860@PEAK.ORG> (forrerj@peak.org) 

Subject: Re: [HFSIG:1350] How to define a new protocol 


>I am looking for suggestions on how to define a protocol. Shall I follow the 
>way that the CCIR did theirs, i.e., a couple of state diagrams and notes? I 


No, that's one of the xworst* ways. 


Write your code. Make it work. Clean it up and release it as a 
reference implementation. Also write a pseudo-code description that 
follows it reasonably closely (could be done as comments on the actual 
code). 


That's how you aid somebody else in producing their own implementation, 
which is after all the goal of writing a standard. 


Phil 


From chbrain@dircon.co.uk Wed Jul 24 05:46:14 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id FAA27309 for <hfsig@tapr.org>; Wed, 24 Jul 
1996 05:46:11 -0500 (CDT) 
Received: by felix.dircon.co.uk id AA06443 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Wed, 24 Jul 1996 11:46:08 +0100 
Message-Id: <199607241046.AA06443@felix.dircon.co.uk> 
Received: from gw2-113.pool.dircon.co.uk(194.112.35.113) by amnesiac via smap 
(V1.3) 
id sma006422; Wed Jul 24 11:45:47 1996 
X-Sender: chbrain@popmail.dircon.co.uk 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Wed, 24 Jul 1996 11:34:21 +0100 
To: hfsig@tapr.org 
From: chbrain@dircon.co.uk (Charles Brain) 
Subject: Re: [HFSIG:1351] Re: HF bandwidth 


>Well, they'll still have their limits. I want no limits. Or at least a 


>radio with a fairly wide IF xand* the ability to frequency hop reasonably fast. 
> 

>Phil 

> 

> 

Hi Phil, 

What sort of hop rates, many hops per symbol (ie fast) or many symbols 

per hop (slow)? 


I guess if you are talking MFSK you are looking at fast hopping and 
non-coherent detection ? 


I wonder what the 'settling' time of the DDS chips are ( at reasonable cost). 


I suppose a number of synthesisers could be used and then switch 
between them to achieve the hop rate. 


- Charles 


From sailer@ife.ee.ethz.ch Wed Jul 24 06:28:07 1996 

Received: from ife.ee.ethz.ch (ife-ifel.ee.ethz.ch [129.132.25.65]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id GAA28795 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
06:27:48 -0500 (CDT) 

Received: from eldrich (sailer@eldrich.ee.ethz.ch [129.132.25.145]) by 
ife.ee.ethz.ch (8.7.5/8.7.5) with SMTP id NAA21360 for <hfsig@tapr.org>; Wed, 24 
Jul 1996 13:27:44 +0200 (MET DST) 

Sender: sailer@ife.ee.ethz.ch 

Message-ID: <31F608B0.33590565@ife.ee.ethz.ch> 

Date: Wed, 24 Jul 1996 13:27:44 +0200 

From: Thomas Sailer <sailer@ife.ee.ethz.ch> 

Organization: IfE 

X-Mailer: Mozilla 3.0b5Gold (X11; I; SunOS 4.1.3 U1 sun4m) 

MIME-Version: 1.0 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1356] Re: HF bandwidth 

References: <199607241046.AA06443@felix.dircon.co.uk> 

Content-Type: text/plain; charset=us-ascii 

Content-Transfer-Encoding: 7bit 


Charles Brain wrote: 


> I wonder what the 'settling' time of the DDS chips are ( at reasonable cost). 
Almost instantaneos. That is within less than 20 cycles of the 

DDS clock, which is typically 20 MHz or greater 

(with the quite old AD DDS AD7008, as an example) 

Cost is about 20$ (probably much less in larger quantities) 


vy 73s de Tom 


HB9INX/AE4WA 
Thomas (Tom) Sailer EMail: sailer@ife.ee.ethz.ch 
Weinbergstrasse 76 Ham Radio: hb9jnx @ hb9w.che.eu 


CH-8408 Winterthur Phone: ++41 52 222 32 81 


From forrerj@peak.org Wed Jul 24 10:29:09 1996 

Received: from PEAK.ORG (forrerj@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAAQ7888 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
10:29:07 -0500 (CDT) 

Received: (from forrerj@localhost) by PEAK.ORG (8.6.13/8.6.7) id IAA10019; Wed, 24 
Jul 1996 08:29:29 -0700 

Date: Wed, 24 Jul 1996 08:29:29 -0700 (PDT) 

From: Johan Forre <forrerj@peak.org> 

X-Sender: forrerj@kira 

To: hfsig@tapr.org 

cc: hfsig@tapr.org 

Subject: Re: [HFSIG:1349] Re: Alexander wrote.. 

In-Reply-To: <199607240602.CAA15033@growler.ccr-p.ida.org> 

Message-ID: <Pine.SUN.3.91.960724082510 .9548A-100000@kira> 

MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi Bob, 


Thanks for the kind offer, but I'm afraid that those articles from the 
Digital Digest are somewhat incomplete. I don't even think you will be 

able to recreate the waveform, for example how they spaced the waveforms, 
and what measures are taken for crest factor control. I also am missing the 
handshaking protocol without which it's almost impossible to make much 
sense of it. 


The most complete reference that I have seen is on SCS's web page. Even 
that is not complete, but it's better than nothing at all. 


--Johan 


On Wed, 24 Jul 1996, Bob McGwier wrote: 


I am in possession of three articles about PACTOR II. It contains everything 
except the details of the interleaving algorithm and the fallback/upgrade 
algorithm. They are written by the PACTOR folks for publication. No, 

I am not willing to make a thousand copies for people. It was published in 
the Digital Digest I believe but I would have to look and I won't be able 

to for at least three weeks (when I begin unpacking at our new residence, 

we are moving a whole five blocks). Someone might check on this. 


Bob 


VVVV VV VV VV VV 


From forrerj@peak.org Wed Jul 24 10:34:52 1996 

Received: from PEAK.ORG (forrerj@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAAQ8298 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
10:34:51 -0500 (CDT) 

Received: (from forrerj@localhost) by PEAK.ORG (8.6.13/8.6.7) id IAA10700; Wed, 24 
Jul 1996 08:35:12 -0700 


Date: Wed, 24 Jul 1996 08:35:12 -0700 (PDT) 

From: Johan Forre <forrerj@peak.org> 

X-Sender: forrerj@kira 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1351] Re: HF bandwidth 

In-Reply-To: <199607240808 .BAA17329@servo.qualcomm. com> 
Message-ID: <Pine.SUN.3.91.960724083021 .9548B-100000@kira> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi Phil, 


On Wed, 24 Jul 1996, Phil Karn wrote: 


> But it's precisely those 300 baud/1 KHz restrictions that I want to eliminate. 
> Eventually I want to spread over the whole band with frequency hopping, but 

> to start I'd like to do MFSK over SSB bandwidths. 

> 

> Phil 

> 

> 


Ah - now you're talking. I would bet that if you can demonstrate such a 
system and show it not to be the monster that folks believe it to be, you 
may be surprised how it will be accepted. 


I still think the time is ripe for folks to start developing all-digital 
transcievers for these purposes, i.e., wider IF's with SS capabilities. 


--Johan 


From chbrain@dircon.co.uk Wed Jul 24 11:57:17 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA11557 for <hfsig@tapr.org>; Wed, 24 Jul 
1996 11:57:14 -0500 (CDT) 
Received: by felix.dircon.co.uk id AA00Q768 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Wed, 24 Jul 1996 17:57:06 +0100 
Message-Id: <199607241657 .AA00768@felix.dircon.co.uk> 
Received: from gw2-103.pool.dircon.co.uk(194.112.35.103) by amnesiac via smap 
(V1.3) 

id smaQ00692; Wed Jul 24 17:56:31 1996 
X-Sender: chbrain@popmail.dircon.co.uk 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii' 
Date: Wed, 24 Jul 1996 17:45:00 +0100 
To: hfsig@tapr.org 
From: chbrain@dircon.co.uk (Charles Brain) 
Subject: Yet Another Free Maths Program 


For those of you into manipulating all things mathematical try out the 


shareware program produced by MathViews at .. 


http: //www.mathwizards.com/ 


By the way I assume no-one has seen a copy of the ECC book I was asking 
about. I have ordered a copy, I will let you know if I think it is any good. 


- Charles 


From Robert.Glassey@nmp.nokia.com Wed Jul 24 12:06:17 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id MAA12048 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
12:06:15 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id UAA03188; Wed, 24 Jul 1996 20:05:42 
+0300 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AAQ80657752; Wed, 24 Jul 1996 20:02:32 +0300 
X-Openmail-Hops: 2 
Date: Wed, 24 Jul 96 18:02:55 +0100 
Message-Id: <H0000292021c57d9@MHS> 
In-Reply-To: <Pine.SUN.3.91.960724083021.9548B-100000@kira> 
Subject: [HFSIG:1359] Re: HF bandwidth 
Mime-Version: 1.0 
To: forrerj@peak.org, hfsig@tapr.org 
Content-Type: text/plain; charset=ISO-8859-1; name="[HFSIG:1359]" 
Content-Transfer-Encoding: 7bit 


> On Wed, 24 Jul 1996, Phil Karn wrote: 

>> But it's precisely those 300 baud/1 KHz restrictions that I want to 
>> eliminate. Eventually I want to spread over the whole band with 

>> frequency hopping, but to start I'd like to do MFSK over SSB 

>> bandwidths. 


Ah - now you're talking. I would bet that if you can demonstrate such 
a system and show it not to be the monster that folks believe it to 
be, you may be surprised how it will be accepted. 


VV VV NV 


--Johan 


It would be very interesting to see it demonstrated in reality. I have 
never seen anything to sufficently prove that it would work even in 
theory. Not wanting to be a spoil sport here, but it appears to me that 
the widespread objections are founded in solid laws of physics. 


Consider this: 
The noise floor on 20m is about -120 to -110 dBm in a 3kHz bandwidth 


using an isotropic antenna. 3 dB degradation can make or break a DX 
contact so interference must be -120dBm or lower. 


Pathloss at 1km is 55dB for freespace, and probably around 70dB given 
real ground effects (into the same isotropic rx antenna, since only 
relative RX levels are important - unless you antenna is really bad). 


Thus and interference must be less than -50dBm in 3Khz bandwidth at the 
transmitter. Over 300Khz, the total transmit power must be less than 
-30dBm, or 1 microwatt to ovoid interference to a DXer 1km away, 
regardless of the spreading method. (assuming power is evenly spread). 


A narrow band mode can transmit easily 100W without causing 
interference, even to his neighbour 20 meters away. Thus the narrow band 
guy has a full x*x*x 80 dB *x*** power advantage! and he dosn't have to 
deal with dozens of high power signals on the band that would interfere 
with the wide band guy. 80dB is a lot of anything however you look at it 
and you would be giving it up if you went for a whole band spreading 
mode. The narrow band mode can also operate 600 stations in 300kHz, with 
no interference, and then reuse frequencies with a 10dB capture effect. 


How can you possibly turn this situation into an advantage? 


. I'd really like to know, so far no one has been able to show me. 


Cheers, 
Rob GOVTQ 


From FORRERIJ@frl.orst.edu Wed Jul 24 13:00:29 1996 
Received: from cornus.FSL.ORST.EDU (root@FSL.ORST.EDU [128.193.112.105]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA15556 for <hfsig@tapr.org>; Wed, 24 Jul 
1996 13:00:27 -0500 (CDT) 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by cornus.FSL.ORST.EDU 
(8.6.9/8.6.9) with ESMTP id LAA19395 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
11:00:25 -0700 
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21); 
24 Jul 96 11:00:24 PST8PDT 
Received: from SpoolDir by FRL (Mercury 1.21); 24 Jul 96 11:00:03 PST8PDT 
From: "Johan Forrer" <FORRERIJ@fr1l.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Wed, 24 Jul 1996 11:00:01 -0800 
Subject: APT with the EVM (fwd) 
Priority: normal 
X-mailer: Pegasus Mail v3.22 
Message-ID: <1DC7AF94303@frl.orst.edu> 


Hi all, 


Here is some good news for those wanting to play some more with the 
56K EVM. I just received an e-mail from Jabi EA2ARU: 


73's and enjoy, 


--Johan 


SSS esse Forwarded Message Follows ------- 
I have uploaded to ftp.tapr.org:/tapr/SIG/hfsig/upload the file evmapt.zip 


This code permits receiving APT transmissions with an EVM board and 
JVFAX 7.1 It is based on a work of Craig Newell, VK4YEQ and has been 
adapted to EVM56002 by Jabi Agirre EA2ARU. 


It has been succesfully tested. We are open to sugestions and 
comments. 
Jabi Agirre EA2ARU 

govier02@spritel.es 

The real connaisseur 


Eduardo Jacob EA2??? (got license, waiting for callsign) 
jtpjatae@bi.ehu.es 
edu@kender.es 
Work in this project: Packager, Readme composer, Internet 
interface, public relations... 


Eduardo Jacob - Area de Ingenieria Telematica 
Departamento de Electronica y Telecomunicaciones 


ETSII y de IT Tel: +34-(9)4-427 8055 
UPV / EHU Fax: +34-(9)4-441 4041 
Alda Urquijo s/n E-mail: jtpjatae@bi.ehu.es 
E-48013 - Bilbao (Spain) : 100021,2212 Compuserve 


From forrerj@peak.org Wed Jul 24 13:22:55 1996 

Received: from PEAK.ORG (forrerj@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id NAA16889 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
13:22:53 -0500 (CDT) 

Received: (from forrerj@localhost) by PEAK.ORG (8.6.13/8.6.7) id LAA27626; Wed, 24 
Jul 1996 11:23:15 -0700 

Date: Wed, 24 Jul 1996 11:23:15 -0700 (PDT) 

From: Johan Forre <forrerj@peak.org> 

X-Sender: forrerj@kira 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1360] Yet Another Free Maths Program 

In-Reply-To: <199607241657.AAQ0768@felix.dircon.co.uk> 

Message-ID: <Pine.SUN.3.91.960724111930.26831A-100000@kixra> 

MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Wed, 24 Jul 1996, Charles Brain wrote: 


By the way I assume no-one has seen a copy of the ECC book I was asking 
about. I have ordered a copy, I will let you know if I think it is any good. 


- Charles 


VV VV VV WV 


I have ordered a copy and will probably have it by the end of the 

week. Will let you know my thoughts. I own three other cookbook-style 
books by the same author and although not very well organized, I must 
admit that I have revisited all of them a number of times. The last one I 
got was on digital filter design. It also contained a disk. 


My two cents worth. 
--Johan 


From forrerj@peak.org Wed Jul 24 13:56:46 1996 

Received: from PEAK.ORG (forrerj@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id NAA18332 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
13:56:44 -0500 (CDT) 

Received: (from forrerj@localhost) by PEAK.ORG (8.6.13/8.6.7) id LAAQ0929; Wed, 24 
Jul 1996 11:57:06 -0700 

Date: Wed, 24 Jul 1996 11:57:05 -0700 (PDT) 

From: Johan Forre <forrerj@peak.org> 

X-Sender: forrerj@kira 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1355] Re: How to define a new protocol 

In-Reply-To: <199607240926.CAA17580@servo. qualcomm. com> 

Message-ID: <Pine.SUN.3.91.960724114508 .29586A-100000@kira> 

MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi Phil, 


On Wed, 24 Jul 1996, Phil Karn wrote: 


>I am looking for suggestions on how to define a protocol. Shall I follow the 
>way that the CCIR did theirs, i.e., a couple of state diagrams and notes? I 


No, that's one of the xworst* ways. 


Write your code. Make it work. Clean it up and release it as a 
reference implementation. Also write a pseudo-code description that 
follows it reasonably closely (could be done as comments on the actual 
code). 


That's how you aid somebody else in producing their own implementation, 
which is after all the goal of writing a standard. 


VV VV VV VV VV VV VV 


Phil 


That would be fairly consise, I agree, but like a loner would work (perhaps 
great minds do work alone? - do they?). I am not sure how we would be 

able to open some topic related to some nitty-griity detail before 
investing time and effort in a real implementation. For example: I 

would like to provide for three modes in QUATOR: 


Mode A: unconnected broadcast with full ECC 
Mode B: Hybrid ARQ for keyboarding 
Mode C: networked (CDMA ?) 


First; is it a good idea, if not what would be objectionable. If it is 
acceptable, what would do we need to cater for in message headers. Perhaps 
some graphical representation such as a state diagram or flow diagram can 
get to the substance easier. 


Suggestions ? 
--Johan 


From zs6awk@global.co.za Wed Jul 24 15:07:56 1996 

Received: from 1in01.global.co.za (1in01.global.co.za [196.3.164.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id PAA21751 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
15:07:49 -0500 (CDT) 

Received: from anx_pt_8.global.co.za (anx_pt_8.global.co.za [196.3.165.208]) by 
lin01.global.co.za (8.7.3/8.7.3) with SMTP id WAA17914 for <hfsig@tapr.org>; Wed, 
24 Jul 1996 22:06:23 -0200 (GMT) 

Message-Id: <199607250006 .WAA17914@1in01.global.co.za> 

X-Sender: zs6awk@mail.global.co.za 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Wed, 24 Jul 1996 22:08:33 +0200 

To: hfsig@tapr.org 

From: zs6awk@global.co.za (Danie Brynard) 

Subject: Re: [HFSIG:1350] How to define a new protocol 


Just a thought: 


Johan I find those formal definitions difficult to understand. Why not 
implement something practical where one play while you learn about the new 
protocol ? For instance something that will run on a DSP56002EVM or perhaps 
a 100MHz Pentuim and then interested experimenters can write it over for 
other platforms. Or is this too amateurish ? :-) 


danie 


>Hi all, 

> 

>I am looking for suggestions on how to define a protocol. Shall I follow the 
>way that the CCIR did theirs, i.e., a couple of state diagrams and notes? I 
>found it to be comprehensive enough to build your own code implementation 
>from it. 

> 

>Seem to remember some time ago, I read somewhere, of the exsistance of a 
>formal language to do this kind of thing. As far as I remember it was a 
>structured definition language where one could travel down a tree to unfold 
>lower levels of more complex parts. But my memory is vague. 

> 

> 

>Thanks, 

> 

>--Johan 

> 


> 
> 
> 


From forrerj@peak.org Wed Jul 24 16:07:55 1996 

Received: from PEAK.ORG (forrerj@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id QAA25105 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
16:07:47 -0500 (CDT) 

Received: (from forrerj@localhost) by PEAK.ORG (8.6.13/8.6.7) id OAA13647; Wed, 24 
Jul 1996 14:08:07 -0700 

Date: Wed, 24 Jul 1996 14:08:07 -0700 (PDT) 

From: Johan Forre <forrerj@peak.org> 

X-Sender: forrerj@kira 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1365] Re: How to define a new protocol 

In-Reply-To: <199607250006.WAA17914@1in01.global.co.za> 

Message-ID: <Pine.SUN.3.91.960724133916.9845A-100000@kira> 

MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Wed, 24 Jul 1996, Danie Brynard wrote: 


> Just a thought: 

> 

> Johan I find those formal definitions difficult to understand. Why not 

> implement something practical where one play while you learn about the new 
> protocol ? For instance something that will run on a DSP56002EVM or perhaps 
> a 100MHz Pentuim and then interested experimenters can write it over for 

> other platforms. Or is this too amateurish ? :-) 

> 

> danie 

> 


No, not a bad idea if you are in learning mode and the scope of things 


remain fairly constrained. 


However, real life protocol implementation details, such as all the 
exceptions to the rule, and special cases, gets in the way and things 

tend to get pretty thick and unwieldy real fast. For example, have a look 
at my Pactor I implementation where have supplied both C and assembly 
source code (available in the HFSIG "upload" area as TORLIB.ZIP). See if 
you can make head or tail of the actual protocol from that :-). This was 
not intentional, but evolution. This is a good example of what tend to 
happen - in the push to get things done, too little effort done to document 
things properly. Once it works, one loose interest in the details. 


I sense that the protocol definition should be timeless, and preferably not 
tied to any particular DSP or RISC architecture. This way it would remain 
there for posterity and give folks the chance to use whatever platform 

they feel comfortable with, i.e., sound card, EVM or Pentium. 


Thanks for the feedback, 


--Johan 


From karn@qualcomm.com Wed Jul 24 16:51:51 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id QAA27026 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
16:51:49 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
OAAO2722; Wed, 24 Jul 1996 14:51:18 -0700 (PDT) 

Date: Wed, 24 Jul 1996 14:51:18 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607242151 .0AAQ2722@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199607241046.AA06443@felix.dircon.co.uk> (chbrain@dircon.co.uk) 
Subject: Re: [HFSIG:1356] Re: HF bandwidth 


>What sort of hop rates, many hops per symbol (ie fast) or many symbols 
>per hop (slow)? 


Fast hopping (more than one symbol per hop) entails noncoherent 
combining losses, so that doesn't make a whole lot of sense unless 
you're in a hostile anti-jam environment. One symbol per hop seems 
like a reasonable maximum. If that's too fast, we could hop less 
often, as long as the rate is still fast enough to exploit frequency 
diversity and produce a uniform loading on the band. 


>I guess if you are talking MFSK you are looking at fast hopping and 
>non-coherent detection ? 


Non-coherent detection, yes. Basically you can think of the whole band as 
containing N tones. For each symbol, you pick a subset M out of N and then 
transmit the one tone out of M that corresponds to the encoded data. 


It doesn't really matter how you pick the subset M of N, so you might 
as well group them together. That means you can use a IF bandwidth that's 
smaller than the entire band and hop around with a DDS. 


>I wonder what the 'settling' time of the DDS chips are ( at reasonable cost). 


A true DDS has no settling time -- it hops essentially instantaneously. Of 
course, a hybrid DDS/PLL will behave differently. 


From karn@qualcomm.com Wed Jul 24 16:58:59 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id QAA27195 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
16:58:55 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
OAAO2751; Wed, 24 Jul 1996 14:58:23 -0700 (PDT) 

Date: Wed, 24 Jul 1996 14:58:23 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607242158.0AAQ2751@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <Pine.SUN.3.91.960724083021.9548B-100000@kira> (message from Johan 
Forre on Wed, 24 Jul 1996 10:44:34 -0500 (CDT)) 

Subject: Re: [HFSIG:1359] Re: HF bandwidth 


>Ah - now you're talking. I would bet that if you can demonstrate such a 
>system and show it not to be the monster that folks believe it to be, you 
>may be surprised how it will be accepted. 


Based on my experience so far promoting the ARRL proposal for more 
liberal spread spectrum rules, I'm skeptical. Everyone keeps screaming 
about "raising the noise floor", and they don't accept arguments that, 
on average, the noiset+interference floor would actually be xlowerx on 
a crowded band with power controlled spread spectrum than with our 
present uncontrolled narrowband techniques. 


Phil 


From karn@qualcomm.com Wed Jul 24 17:56:28 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id RAAQ0304 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
17:56:26 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
PAAQ9032; Wed, 24 Jul 1996 15:55:55 -0700 (PDT) 

Date: Wed, 24 Jul 1996 15:55:55 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607242255 .PAAQ9032@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <Pine.SUN.3.91.960724133916.9845A-100000@kira> (message from Johan 
Forre on Wed, 24 Jul 1996 16:24:49 -0500 (CDT)) 

Subject: Re: [HFSIG:1366] Re: How to define a new protocol 


>I sense that the protocol definition should be timeless, and preferably not 
>tied to any particular DSP or RISC architecture. This way it would remain 
>there for posterity and give folks the chance to use whatever platform 


>they feel comfortable with, i.e., sound card, EVM or Pentium. 


That's why you can write the standard in pseudo-code, i.e., an English 
description that is still structured like a computer program. 


The problem I have with logic diagrams, SDL diagrams, and conventional 
English prose descriptions of protocols (e.g., anything in the ITU-T 

X. series) is that they are many steps removed from actual 
implementations. In fact, the people who write them frequently have 
little or no actual programming experience. And these things are 
invariably replete with subtle errors and dead ends (special cases 

that are not handled at all). Or at least they're way behind the actual 
implementations. 


A standard written in pseudo-code that is derived from an actual 
working implementation has many advantages. First, having been derived 
from a working implementation means it's much more likely to be 
correct and to cover all the special cases. Second, it's much closer 
to the form a programmer would want to implement in some other 
computer language. Programming is pretty much universal; the 
differences between computer languages are relatively minor compared 
to the similarities that are captured in pseudocode. 


A good example of a fairly complex protocol specified in pseudo-code 

is the internet Transmission Control Protocol (TCP) in RFC-793. I wrote 
my own implementation in C that closely follows the pseudo-code, 

and I found it far easier than implementing X.25 LAPB from the spec. 


Today, given the enormous popularity in C I would give serious 
consideration to making a well-commented portable C implementation the 
official description of a protocol. After all, a computer language is 
designed to be as unambiguous as possible. 


Phil 


From karn@qualcomm.com Wed Jul 24 19:30:42 1996 

Received: from zeus.qualcomm.com (zeus.qualcomm.com [129.46.50.42]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id TAAQ5148 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
19:30:36 -0500 (CDT) 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
zeus.qualcomm.com (8.7.5/1.2d/8.7.2/1.9) with ESMTP id RAAQ9151 for 
<hfsig@tapr.org>; Wed, 24 Jul 1996 17:30:05 -0700 (PDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
RAAO9259; Wed, 24 Jul 1996 17:28:49 -0700 (PDT) 

Date: Wed, 24 Jul 1996 17:28:49 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607250028.RAAOQ9259@servo.qualcomm. com> 

To: hfsig@tapr.org 

Cc: karn@qualcomm.com 

In-reply-to: <H0000292021c57d9@MHS> (Robert.Glassey@nmp.nokia.com) 

Subject: Re: [HFSIG:1361] Re: HF bandwidth 


>It would be very interesting to see it demonstrated in reality. I have 


>never seen anything to sufficently prove that it would work even in 
>theory. Not wanting to be a spoil sport here, but it appears to me that 
>the widespread objections are founded in solid laws of physics. 


Not really. To the extent that they're based on any analyses at all, 
the widespread objects are based more in absolute worst-case analyses, 
without looking at the big picture. 


>The noise floor on 20m is about -120 to -110 dBm in a 3kHz bandwidth 
>using an isotropic antenna. 3 dB degradation can make or break a DX 
>contact so interference must be -120dBm or lower. 


How often is noise (by which I assume you mean natural background 
noise) the limiting factor on 20m? As compared to QRM? 


>Pathloss at 1km is 55dB for freespace, and probably around 70dB given 
>real ground effects (into the same isotropic rx antenna, since only 
>relative RX levels are important - unless you antenna is really bad). 


How many serious 20m DXers use isotropic antennas? Wouldn't it be more 
reasonable to consider the front-to-back and front-to-side ratios of 
typical 3-element yagis? 


>Thus and interference must be less than -50dBm in 3Khz bandwidth at the 
>transmitter. Over 300Khz, the total transmit power must be less than 
>-30dBm, or 1 microwatt to ovoid interference to a DXer 1km away, 
>regardless of the spreading method. (assuming power is evenly spread). 


Ah, but it xdoesx depend on the spreading method. Only direct sequence 
spreads its power into a uniform, noiselike distribution. Consider 
instead a medium-rate M-ary FSK system like I propose. Pick a symbol 
duration on the order of 50ms (20 Hz). A 64-ary scheme would therefore 
require 64x20=1280 Hz at any given instant. Now let's frequency hop on 
every symbol over the 350 KHz of the 20m band. 350 Khz/1280 Hz ~= 

273. With a hopping rate of 20 Hz, one would expect, on average, to 
hit every 1280 Hz channel once every 273/20 = 13.7 seconds or so. (If 
the hopping pattern were a linear frequency chirp, this would happen 
exactly periodically). For a narrower target (such as a 400 Hz CW 
filter, which I assume you'd be using if you're really seriously 
working such weak DX), the hit rate would be proportionately longer: 
once every 43.75 seconds. And each "hit" would last just 50ms. 


How often do fades occur on 20m? Static crashes? Intermittent QRM 
from key-down VFO spotting, key clicks, SSB spillover and "didit-dit" 
queries? Less often than once per 45 seconds? How long do they last? 
Shorter than 50ms? 


Keeping everything else constant, yes, the average interference power 
is the same for frequency hopping as for direct sequence. But I 
suspect that most narrowband operators would find strong QRM a small 
fraction of the time to be less objectionable than continuous, 
low-level QRM (continuous at least when transmitting). 


It would help to study the behavior of typical HF transceivers when 
designing such a modulation scheme. How do their AGCs respond to very 
short bursts of a strong signal? How about their now-unused 
"woodpecker" filters, could they be used to blank a somewhat shorter 
symbol time altogether? Shorter M-ary symbols would probably be 
preferable anyway, to increase the user data rate. 


Bear in mind that the commonly expressed objections to spread spectrum 
deal solely with the near-far problem. First of all, I just don't 
accept that near-far is unique to spread spectrum, as anybody who has 
ever lived next door to another active ham knows very well. Sine waves 
are absolutely perfectly orthogonal only in theory. Real filters 
aren't perfect, real power amplifiers produce intermodulation 
distortion, and real VCOs produce phase noise. 


Second, there are other effective ways to mitigate the near-far 
problem beyond what I've already described, such as designating DX 
subbands and excluding them from the frequency hopping list. Having 
subbands for "DX", "local", "regional" and the like -- without regard 
to mode -- makes far more sense than our present scheme of dividing 
them up by emission mode. And that's not just because modern 
technology is hopelessly blurring the distinctions between "voice", 
"image" and "data". 


And third, given the widespread use of spread spectrum, any occasional 
increase in QRM to a narrowband receiver from a nearby SS station 
will, on average, be more than made up for by a significant xdecreasex 
in total interference from distant stations, thanks to the increased 
power efficiencies SS makes possible. As crowded as the HF bands are, 
it is rare to find an HF link truly limited by thermal or natural 
noise -- except perhaps when the band is closed. So postulating that 
limit in a SS QRM analysis is simply unrealistic. In practice, almost 
every real HF link is ultimately limited by the din of QRM from many 
distant stations reusing the same channel. 


And that's what makes it in the direct interest of the narrowband user 
that power-controlled spread spectrum become as widespread (!) as 
possible, because that's the only way to reduce the total amount of RF 
power floating around as background QRM. 


I understand that these arguments may seem counterintuitive. But they 
are nonetheless correct when you look at the whole picture instead of 
drawing conclusions from unrealistic and limited assumptions. 


Phil 


From karn@qualcomm.com Wed Jul 24 20:26:36 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id UAAQ7753 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
20:26:33 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
SAA15628; Wed, 24 Jul 1996 18:26:02 -0700 (PDT) 

Date: Wed, 24 Jul 1996 18:26:02 -0700 (PDT) 


From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607250126.SAA15628@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <Pine.SUN.3.91.960724114508 .29586A-100000@kira> (message from Johan 
Forre on Wed, 24 Jul 1996 14:02:01 -0500 (CDT)) 

Subject: Re: [HFSIG:1364] Re: How to define a new protocol 


>Mode A: unconnected broadcast with full ECC 
>Mode B: Hybrid ARQ for keyboarding 
>Mode C: networked (CDMA ?) 


Looks good. I've soured somewhat on type II hybrid ARQ/FEC since 
writing my paper some years ago, because I've learned that in practice 
it is very difficult to coherently combine symbols over a wide 

span. Coherent PSK loops have difficulty recovering carrier phase and 
noncoherent M-ary FSK schemes have their threshold effects. And of 
course whatever sync mechanism you use has to be much more robust than 
the coding, or it all breaks down much as a damaged CD will cause the 
typical CD player to skip a track well before it reaches the error 
correcting limit of the dual-RS code. 


So it's probably just as well to stick with a type I hybrid (i.e., 
punt on the frame combining) as long as you have some sort of 
adaptation mechanism where you can change the code and/or modulator 
symbol rates. 


Phil 


From karn@qualcomm.com Wed Jul 24 20:29:31 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id UAAQ7802 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
20:29:30 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
SAA15642; Wed, 24 Jul 1996 18:28:58 -0700 (PDT) 

Date: Wed, 24 Jul 1996 18:28:58 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607250128.SAA15642@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199607231147 .EAAQ6903@ravel.n2.net> (k6ésti@n2.net) 

Subject: Re: [HFSIG:1333] HF Modem Bandwidth 


>10 dB is a lot--how much wider are you thinking, Phil? Tell me you don't 
>want all of 20 meters! 


As much of it as I can get, except perhaps for small DX windows. In 
exchange, of course, I'll do automatic power control and implement a 
highly efficient modem that will seriously minimize my total RF power 
requirements. 


>I think to go much beyond 500 Hz in the CW/DATA portion of the bands would 
>add years to the introduction of a new protocol. The educational effort 


>required would be enormous. I think you could probably get the FCC to go 
>along--it's the general ham population that would react very negatively to 
>any kind of wideband proposal. At the minimum I think wideband signals 


You are probably right, but it's easier to change the rules than the 

laws of physics. So there's really no choice. You're absolutely right, 

the FCC is far more enlightened about these things, but they won't change 
the rules until the general population can be educated enough to not oppose 
it in knee-jerk fashion. 


Phil 


From k6sti@n2.net Wed Jul 24 22:56:34 1996 

Received: from ravel.n2.net (ravel.n2.net [204.250.22.20]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id WAA16688 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
22:56:32 -0500 (CDT) 

Received: from ppp160.n2.net (ppp160.n2.net [204.250.22.160]) by ravel.n2.net 
(8.6.12/8.6.12) with SMTP id UAAQ1497 for <hfsig@tapr.org>; Wed, 24 Jul 1996 
20:58:23 -0700 

Date: Wed, 24 Jul 1996 20:58:23 -0700 

Message-Id: <199607250358.UAA01497@ravel.n2.net> 

X-Sender: k6sti@mail.n2.net 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: k6ésti@n2.net (Brian Beezley) 

Subject: Re: [HFSIG:1370] Re: HF bandwidth 


Phil, I admire the spirited way in which you defend the idea of HF spread 
spectrum, but I think SS is incompatible with traditional narrowband modes. 
I believe separate SS and narrow-emission HF band segments are necessary. 
I'll comment below on specific points, but the gist of my argument is as 
follows: When using a narrowband mode in a crowded band, it's always 
possible to find a substantially clear spot, except perhaps during contest 
weekends. Therefore, you really are limited by atmospheric and cosmic 
noise, not other transmitters. Widespread adoption of SS likely would raise 
the noise floor of all clear spots on a band and cause random--if 
infrequent--QRM blips from nearby SS transmitters. 


>>It would be very interesting to see it demonstrated in reality. I have 
>>never seen anything to sufficently prove that it would work even in 
>>theory. Not wanting to be a spoil sport here, but it appears to me that 
>>the widespread objections are founded in solid laws of physics. 

> 

>Not really. To the extent that they're based on any analyses at all, 
>the widespread objects are based more in absolute worst-case analyses, 
>without looking at the big picture. 

> 

>>The noise floor on 20m is about -120 to -110 dBm in a 3kHz bandwidth 
>>using an isotropic antenna. 3 dB degradation can make or break a DX 


>>contact so interference must be -120dBm or lower. 

> 

>How often is noise (by which I assume you mean natural background 
>noise) the limiting factor on 20m? As compared to QRM? 


For me it's always the limiting factor. The way I use HF is to QSY whenever 
QRM occurs. I don't fight it--it's too easy to find a clear spot. 


> 

>>Pathloss at 1km is 55dB for freespace, and probably around 70dB given 
>>real ground effects (into the same isotropic rx antenna, since only 
>>relative RX levels are important - unless you antenna is really bad). 
> 

>How many serious 20m DXers use isotropic antennas? Wouldn't it be more 
>reasonable to consider the front-to-back and front-to-side ratios of 
>typical 3-element yagis? 


You're right that nobody uses isotropic antennas, but lots of people use 
dipoles with low directivity. I use two at right angles myself. But even 
if I used a good 3-element Yagi with 60-degree beamwidth, statistically it 
would reduce the incidence of near-transmitter, narrowband QRM only by a 
factor of six. I believe that widespread adoption of SS on HF in the same 
subbands as current narrowband modes would make this factor insignificant. 


> 

>>Thus and interference must be less than -50dBm in 3Khz bandwidth at the 
>>transmitter. Over 300Khz, the total transmit power must be less than 
>>-30dBm, or 1 microwatt to ovoid interference to a DXer 1km away, 
>>regardless of the spreading method. (assuming power is evenly spread). 
> 

>Ah, but it *does*x depend on the spreading method. Only direct sequence 
>spreads its power into a uniform, noiselike distribution. Consider 
>instead a medium-rate M-ary FSK system like I propose. Pick a symbol 
>duration on the order of 50ms (20 Hz). A 64-ary scheme would therefore 
>require 64x20=1280 Hz at any given instant. Now let's frequency hop on 
>every symbol over the 350 KHz of the 20m band. 350 Khz/1280 Hz ~= 

>273. With a hopping rate of 20 Hz, one would expect, on average, to 
>hit every 1280 Hz channel once every 273/20 = 13.7 seconds or so. (If 
>the hopping pattern were a linear frequency chirp, this would happen 
>exactly periodically). For a narrower target (such as a 400 Hz CW 
>filter, which I assume you'd be using if you're really seriously 
>working such weak DX), the hit rate would be proportionately longer: 
>once every 43.75 seconds. And each "hit" would last just 50ms. 


I wouldn't want to engage in an SSB conversation overlayed with 50 ms tone 
bursts unless they occurred less frequently than once every few minutes. To 
put this in perspective, a 50-ms tone burst is the length of a 24-wpm Morse 
code dot. 


> 

>How often do fades occur on 20m? Static crashes? Intermittent QRM 
>from key-down VFO spotting, key clicks, SSB spillover and "didit-dit" 
>queries? Less often than once per 45 seconds? How long do they last? 
>Shorter than 50ms? 


If SS and narrowband segments didn't overlap, it wouldn't be necesary to add 
unevadeable SS QRM to the HF woes listed above. 


> 
>Keeping everything else constant, yes, the average interference power 
>is the same for frequency hopping as for direct sequence. But I 
>suspect that most narrowband operators would find strong QRM a small 
>fraction of the time to be less objectionable than continuous, 
>low-level QRM (continuous at least when transmitting). 


Personally, I wouldn't continue a QSO that had strong QRM a small fraction 
of the time. Instead, I'd QSY to a clear spot. But with SS across the 
band, these no longer would be available. 


> 

>It would help to study the behavior of typical HF transceivers when 
>designing such a modulation scheme. How do their AGCs respond to very 
>short bursts of a strong signal? How about their now-unused 
>"woodpecker" filters, could they be used to blank a somewhat shorter 
>symbol time altogether? Shorter M-ary symbols would probably be 
>preferable anyway, to increase the user data rate. 


I don't think AGC response matters. The SS signal still will be reproduced 
at some level. I think SS bursts are too long to blank. Blanking relies on 
the impulse response of the IF filter to bridge a brief blanking gap. This 
doesn't work if the gap is long. (However, linear predictive coding could 
easily bridge a voice gap of several tens of ms.) 


> 

>Bear in mind that the commonly expressed objections to spread spectrum 
>deal solely with the near-far problem. First of all, I just don't 
>accept that near-far is unique to spread spectrum, as anybody who has 
>ever lived next door to another active ham knows very well. Sine waves 
>are absolutely perfectly orthogonal only in theory. Real filters 
>aren't perfect, real power amplifiers produce intermodulation 
>distortion, and real VCOs produce phase noise. 


In 40 years of operating HF, I've never encountered a strong local signal I 
couldn't evade by QSYing down the band a ways (excepting, of course, the 
AGCless Hallicrafters S-38D I used in my novice days that would block out 
the entire 40-meter band when the kid on the next street keyed up.) But the 


recourse of QSYing wouldn't be possible with SS across the band. 


> 

>Second, there are other effective ways to mitigate the near-far 
>problem beyond what I've already described, such as designating DX 
>subbands and excluding them from the frequency hopping list. Having 
>subbands for "DX", "local", "regional" and the like -- without regard 
>to mode -- makes far more sense than our present scheme of dividing 
>them up by emission mode. And that's not just because modern 
>technology is hopelessly blurring the distinctions between "voice", 
>"image" and "data". 


I think this is the solution to the compatibility problem. 


Did you know that many years ago the FCC proposed segmenting HF subbands not 
by emission but by occupied bandwidth? I thought this was a terrific idea! 

The ARRL nixed it, presumably in response to widespread negative membership 

reaction. 


> 

>And third, given the widespread use of spread spectrum, any occasional 
>increase in QRM to a narrowband receiver from a nearby SS station 
>will, on average, be more than made up for by a significant xdecreasex 
>in total interference from distant stations, thanks to the increased 
>power efficiencies SS makes possible. As crowded as the HF bands are, 
>it is rare to find an HF link truly limited by thermal or natural 
>noise -- except perhaps when the band is closed. So postulating that 
>limit in a SS QRM analysis is simply unrealistic. In practice, almost 
>every real HF link is ultimately limited by the din of QRM from many 
>distant stations reusing the same channel. 


This paragraph doesn't at all reflect my HF experience. 


> 

>And that's what makes it in the direct interest of the narrowband user 
>that power-controlled spread spectrum become as widespread (!) as 
>possible, because that's the only way to reduce the total amount of RF 
>power floating around as background QRM. 


I don't experience low-level background QRM. I simply don't put up with it. 


> 

>I understand that these arguments may seem counterintuitive. But they 
>are nonetheless correct when you look at the whole picture instead of 
>drawing conclusions from unrealistic and limited assumptions. 

> 

>Phil 

> 

> 

> 


I vote for separate--but equal!--SS subbands. 


73--Brian, K6STI 
k6sti@n2.net 


From k5yfw@www.kelly-afb.org Thu Jul 25 00:27:20 1996 

Received: from www.kelly-afb.org (www.kelly-afb.org [204.214.204.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id AAA24870 for <hfsig@tapr.org>; Thu, 25 Jul 1996 
00:27:17 -0500 (CDT) 

Received: (from k5yfw@localhost) by www.kelly-afb.org (8.7.1/8.7.1) id AAA11342 
for hfsig@tapr.org; Thu, 25 Jul 1996 00:27:48 -0500 (CDT) 

From: Walt DuBose - K5YFW <k5yfw@www.kelly-afb.org> 

Message-Id: <199607250527 .AAA11342@www.kelly-afb.org> 

Subject: Re: [HFSIG:1352] Re: Message not deliverable 

To: hfsig@tapr.org 

Date: Thu, 25 Jul 1996 00:27:46 -0500 (CDT) 

In-Reply-To: <199607240809.BAA17345@servo.qualcomm.com> from "Phil Karn" at Jul 
24, 96 03:22:48 am 

Reply-To: k5yfw@www.kelly-afb.org 

X-Mailer: ELM [version 2.4 PL24] 

Content-Type: text 


Oh, I'm not but think I'll have lots of help...and I'm not 
underestimating the amount of work/time you and others have put in on 
this "project". Thanks for your effort. 


Walt 


In your message you write: 

> 

> >You guys build the protocol and make it work and I'll use it and die 

> >trying to sell it to the ham community and get the FCC to let it be used. 
> 

> Okay, you're on. Don't underestimate the job you've taken on. Getting an 

> STA for ourselves will be fairly easy. Getting the rules changed to permit 
> general use will be the trick. 

> 

> Phil 

> 


Vv 


| The MicroSoft operating system didn't get as bad as it is overnight, | 
| it has taken over 10 years of careful, calculated development. | 


| The greatest dangers to liberty 
Walt DuBose - K5YFW | lurk in insidious encroachment 
E-Mail k5yfw@www.kelly-afb.org | by men of zeal, well-meaning 
Business Telephone: (210)925-6081 | but without understanding. 
Home Telephone: (210)696-3196 | | 
| - Justice Louis D. Brandeis | 


From s52d@s55tcp.ampr.org Thu Jul 25 01:14:59 1996 

Received: from s55tcp.ampr.org (radio.kud-fp.si [193.2.132.80]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id BAA26618 for <hfsig@tapr.org>; Thu, 25 Jul 1996 
01:14:56 -0500 (CDT) 

Date: Thu, 25 Jul 96 06:34:13 EDT 

Message-Id: <69028@s55tcp.ampr.org> 

From: Iztok Saje <s52d@s55tcp.ampr.org> 

To: hfsig@tapr.org 

Subject: Re: HF bandwith (and UHF) 


Few cents from real life: 

In Slovenia we have users packet QRGs with Wide-bandwith FM radios. 

1 W, 200 kHz wide, TXdelay 10 to 15 ms, robust manchester coding, 

speeds up to 76.8 kbit/sec. 

Experience: This packet is unnoticable to plastic radio users (normal FM 
handies), if you are not really near the wbfm packet station. 


It is not SSB, but plastic radios are also not tecnical miracles. 

(BTW, this is happening on 70cm band). 

I guess noise-blankers, AGCs etc can filter out occasional QRM from SS. 

If woodpecker QRM can be avoided, then SS packet should not be a problem on 
20 m band. 

Best 73, g1 de Iztok 


S52D/WU2D @S50BOX.SVN.EU 
Info abt S5 packet: http://lois.kud-fp.si/hamradio/ 


From hakan.bergzen@enator.se Thu Jul 25 05:20:00 1996 
Received: from gk.enator.se ([147.13.200.1]) by tapr.org (8.7.5/8.7.3/1.9) with 
ESMTP id FAAQ3361 for <hfsig@tapr.org>; Thu, 25 Jul 1996 05:19:49 -0500 (CDT) 
Received: from janus.vxo.telub.se ([147.13.8.25]) by gk.gk.enator.se with SMTP id 
<35980-1>; Thu, 25 Jul 1996 12:20:00 +0100 
Received: from noak.vxo.enator.se by janus.vxo.telub.se with SMTP (PP) 
id <03239-0@janus.vxo.telub.se>; Thu, 25 Jul 1996 12:06:17 +0200 
Received: by noak with Microsoft Mail id <320252A6@noak>; 
Thu, 25 Jul 96 12:10:30 +02 
From: "Bergzen Hakan, KARL" <hakan.bergzen@enator.se> 
To: HFSIG at TAPR <hfsig@tapr.org> 
Subject: Use of block allocations on the HF band? 
Date: Thu, 25 Jul 1996 11:11:00 +0100 
Message-ID: <320252A6@noak> 
Encoding: 57 TEXT 
X-Mailer: Microsoft Mail V3.0 
MIME-Version: 1.0 
Content-Type: Text/plain; charset="US-ASCII" 
Content-Transfer-Encoding: 7bit 


Even though the following does not directly affect the amateur radio 
community some of you migh find the following interesting considering the 
ongoing discussion: 


The discussion regarding the radio Regulations versus a more flexible use of 
HF bandwidth by the introduction of various new techniques are very 
interesting. I am currently engaged in a small working party within ITU-R 
SG9 studying this topic. 


For cost reasons etc. the next generation of professional HF networks will 
operate either unmanned or with very little real-time operator interaction. 
This has promoted the development of automatic HF systems. A number of 
adaptive functions are embedded in these HF systems (the most common one 
being the automatic selection of most suitable traffic frequency) and they 
are all using moderate-to-high speed HF modems. These factors have the 
advantage of achieving a dramatic increase in link availability. (In some 
cases even competing with satellite). 


Background info: As of today around 15000 ALE systems (operating in 
accordance with US MIL-STD-188-141A/FED-STD-1045A) have been procured 
world-wide (two-thirds outside the US). And that is just one of the adaptive 
systems on the market (although probably the largest). Today these 


autoamtic/adaptive systems use most frequencies on the so-called 
non-interference basis (with regard to the notified fixed frequency users). 


However, these systems need to contain fairly large frequency pools, 
covering all sorts of propagation conditions (and interference situations) 
in order to be fully automatic. Therefore the need for a revision of the 
radio regulations concerning the band allocations. Instead of having the 
ITU-R allocating specific frequencies to each user/service it ought to be 
allowed to (if meeting certain to-be-decided conditions) use certain defined 
frequency blocks spread across the entire HF band (similar to the amateur 
radio bands, but much wider). Observe that the approach is not to make a 
new ITU band allocation, merely to allow frequency agile systems to operate 
on some/several of the already defined ITU band allocations thus forming a 
large block allocation. 


The Swedish approach in this working party is that all sorts of frequency 
agile systems should be usable on these frequency blocks, thus not limiting 
it to be just adaptive HF systems but also SS-HF and SS-DS systems. The 
systems to be used must of course be possible to monitor (openly available 
standards or openly procurable) and some sort of network registration at 
ITU-R will probably be needed (to sort out interference complaints from 
other users etc). 


The aim is to have some sort of recommendation ready to be brought to the 
table at WRC-97. Feel free to contact me if you have any thoughts or 
suggestions on what types of (technical) restrictions that ought to be 
incorporated in this scheme. And especially if you are aware of tests, 
reports etc that have studied interference effects. Hopefully this scheme 
ought to reduce the overall band interference levels without causing harmful 
interference to fixed frequency users/services within the block allocations 
(which also remains to be defined). 


Hakan Bergzen (hakan.bergzen@enator.se) 
SM70KI 


From Robert.Glassey@nmp.nokia.com Thu Jul 25 05:28:42 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id FAAQ3415 for <hfsig@tapr.org>; Thu, 25 Jul 1996 
05:28:39 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id NAAQ7669 for <hfsig@tapr.org>; Thu, 
25 Jul 1996 13:28:05 +0300 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AAQ01440293; Thu, 25 Jul 1996 13:24:53 +0300 
X-Openmail-Hops: 2 
Date: Thu, 25 Jul 96 10:34:23 +0100 
Message-Id: <H0000292021d84a7@MHS> 
In-Reply-To: <199607242158 .0AA02751@servo.qualcomm. com> 
Subject: [HFSIG:1368] Re: HF bandwidth 
Sender: Robert.Glassey@nmp.nokia.com 
To: hfsig@tapr.org 


Phil wrote: 

Based on my experience so far promoting the ARRL proposal for more 
liberal spread spectrum rules, I'm skeptical. Everyone keeps screaming 
about "raising the noise floor", and they don't accept arguments that, 
on average, the noiset+interference floor would actually be xlower* on 
a crowded band with power controlled spread spectrum than with our 
present uncontrolled narrowband techniques. 


VV VV VV 


Sorry to be a pain Phil, but I havent seen any such arguments, I've only 
seen SS proponents making bold and unsupported claims while the laws of 
physics appear to dissagree with them. 


The basic SS argument makes several invalid assumptions: 


1/ The bands are so conjested that DX is impossible, and QRM is the 
limiting factor in amateur communications. 


2/ That cooperative, effective power contorl is possible on a global 
scale, both technically (near far problems) and politically. 


3/ That nobody else in your neighbourhood will be transmitting or 
receiving on the same band as you to anyone further than the 
distance between you and your neighbour. The clasic near-far 
problem. 


4/ That all hams prefer local celular type communications to DX. 
5/ That all hams want to operate only one mode. Namely SS. 


I'm actually in favour of SS, but only where appropriate, ie above 2GHz, 
in exclusive SS bands maybe 10 to 100MHz wide, in a celular style high 
speed random access HAM-LAN digital network. I think you would find a 
lot of support for this, inspiring enthusiastic developemnt, but on HF 
you'll always be swimming against the current, fighting a loosing 
battle, where either you or ham radio in general must loose. 


Sorry to be such a spoil sport, lets get back to more realistic HF 
modems and developing an open standard for the next generation of ham 
friendly HF data modems. 


More on standards later.... 
Cheers, 
Rob 


From n4hy@ccr-p.ida.org Thu Jul 25 08:43:48 1996 

Received: from idacrd.ccr-p.ida.org (idacrd.ccr-p.ida.org [206.181.22.66]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id IAA09812 for <hfsig@tapr.org>; Thu, 25 
Jul 1996 08:43:47 -0500 (CDT) 

Received: from idacrd.ccr-p.ida.org (daemon@localhost) by idacrd.ccr-p.ida.org 
(8.7.2/8.7.2) with ESMTP id JAA17505 for <hfsig@tapr.org>; Thu, 25 Jul 1996 
09:44:30 -0400 (EDT) 


Received: from ccr-p.ida.org (xida.ccr-p.ida.org [198.3.6.62]) by idacrd.ccr- 
p.ida.org (8.7.2/8.7.2) with SMTP id JAA17501 for <hfsig@tapr.org>; Thu, 25 Jul 
1996 09:44:29 -0400 (EDT) 

Received: from wahoo.ccr-p.ida.org (wahoo.ccr-p.ida.org [198.3.6.6]) by ccr- 
p.ida.org (8.6.12/8.6.12) with ESMTP id JAA13396 for <hfsig@tapr.org>; Thu, 25 Jul 
1996 09:43:25 -0400 

From: Bob McGwier <n4hy@ccr-p.ida.org> 

Received: (from n4hy@localhost) by wahoo.ccr-p.ida.org (8.7.5/8.7.3) id JAA22782 
for hfsig@tapr.org; Thu, 25 Jul 1996 09:43:24 -0400 (EDT) 

Date: Thu, 25 Jul 1996 09:43:24 -0400 (EDT) 

Message-Id: <199607251343.JAA22782@wahoo.ccr-p.ida.org> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1358] Re: Alexander wrote.. 

In-reply-to: <Pine.SUN.3.91.960724082510.9548A-100000@kira> (message from Johan 
Forre on Wed, 24 Jul 1996 10:43:23 -0500 (CDT)) 


There is enough detail in the articles for you to get the waveforms and 
how they handle crest factor problems (I believe they ignore it and allow 
interleaving and FEC fix it). The handshake protocol is what I meant by 
upgrade/downgrade channels. 


Bob 


From karn@qualcomm.com Thu Jul 25 09:51:25 1996 

Received: from zeus.qualcomm.com (zeus.qualcomm.com [129.46.50.42]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id JAA12509 for <hfsig@tapr.org>; Thu, 25 Jul 1996 
09:51:22 -0500 (CDT) 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
zeus.qualcomm.com (8.7.5/1.2d/8.7.2/1.9) with ESMTP id HAAQ6098 for 
<hfsig@tapr.org>; Thu, 25 Jul 1996 07:50:50 -0700 (PDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
HAAQ0935; Thu, 25 Jul 1996 07:49:35 -0700 (PDT) 

Date: Thu, 25 Jul 1996 07:49:35 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607251449 .HAAQ0935@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199607250358.UAAQ1497@ravel.n2.net> (k6sti@n2.net) 

Subject: Re: [HFSIG:1373] Re: HF bandwidth 


I guess it's not surprising to encounter resistance on this. John 
Costas wrote his paper "Poisson, Shannon and the Radio Amateur" way 
back in 1959, and it was already obvious that it was going to be a 
hard sell. The old ways due hard... 


I have much more to say later, but I wanted to make one quick point. 
The central limit theorem from mathematics says that the sum of a 
sufficiently large number of independent signals approximates a 
Gaussian distribution. The characteristics of the individual signals 
is surprisingly irrelevant, as long as they're independent. Even more 
surprising is just how quickly it kicks in; just a few independent 
sources are enough to make things look very Gaussian. 


As an aside, this explains why Gaussian noise is so common in nature. Most 
natural sources of noise consist of a very large number of independent 
processes that may or may not be Gaussian. A single drop of water splashing 
on the beach doesn't sound very Gaussian, but the crashing surf does. 


So my quick point is this: how do you *xknowx that your link is limited 
by natural background noise? How can you distinguish that from the din 
of QRM from many distant background stations? 


Phil 


From govierO2@sarenet.es Thu Jul 25 11:43:57 1996 

Received: from sarenet.es (sollube.sarenet.es [192.148.167.16]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id LAA17579 for <hfsig@tapr.org>; Thu, 25 Jul 1996 
11:43:52 -0500 (CDT) 

Received: from govier02 (INFOVIA-B-24.sarenet.es [193.148.39.248]) by sarenet.es 
(8.7.5/8.7.2) with ESMTP id SAAQ2267 for <hfsig@tapr.org>; Thu, 25 Jul 1996 
18:21:24 +0200 (MET DST) 

Message-Id: <199607251621.SAA02267@sarenet.es> 

From: "Jabi" <govierO02@sarenet.es> 

To: <hfsig@tapr.org> 

Subject: RE: [HFSIG:1362] APT with the EVM (fwd) 

Date: Thu, 25 Jul 1996 18:26:38 +0200 

X-MSMail-Priority: Normal 

X-Priority: 3 

X-Mailer: Microsoft Internet Mail 4.70.1132 

MIME-Version: 1.0 

Content-Type: text/plain; charset=IS0-8859-1 

Content-Transfer-Encoding: 8bit 


> De: Johan Forrer <FORRERJ@frl.orst.edu> 

> A: hfsig@tapr.org 

> Asunto: [HFSIG:1362] APT with the EVM (fwd) 

> Fecha: miErcoles 24 de julio de 1996 20:02 

> 

> Hi all, 

> 

> 

> Here is some good news for those wanting to play some more with the 
> 56K EVM. I just received an e-mail from Jabi EA2ARU: 
> 

> 73's and enjoy, 

> 

> --Johan 

> 

> 

> 

> aa Forwarded Message Follows ------- 

> 


Vv 


I have uploaded to ftp.tapr.org:/tapr/SIG/hfsig/upload the file 


evmapt.zip 


This code permits receiving APT transmissions with an EVM board and 
JVFAX 7.1 It is based on a work of Craig Newell, VK4YEQ and has been 
adapted to EVM56002 by Jabi Agirre EA2ARU. 


It has been succesfully tested. We are open to sugestions and 
comments. 
Jabi Agirre EA2ARU 

govier02@spritel.es 

The real connaisseur 
Please change de address. e-mail correct is: 
govier02@sarenet.es 


VV VV VV VV VW 


Tnx and 73, de Jabi, EA2ARU. 


Eduardo Jacob EA2??? (got license, waiting for callsign) 
jtpjatae@bi.ehu.es 
edu@kender.es 
Work in this project: Packager, Readme composer, Internet 
interface, public relations... 


Eduardo Jacob - Area de Ingenieria Telematica 
Departamento de Electronica y Telecomunicaciones 

ETSII y de IT Tel: +34-(9)4-427 8055 

UPV / EHU Fax: +34-(9)4-441 4041 

Alda Urquijo s/n E-mail: jtpjatae@bi.ehu.es 
E-48013 - Bilbao (Spain) : 100021,2212 Compuserve 


VV VV VV VV VV VV OV 


From k6sti@n2.net Thu Jul 25 11:52:38 1996 

Received: from ravel.n2.net (ravel.n2.net [204.250.22.20]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id LAA18273 for <hfsig@tapr.org>; Thu, 25 Jul 1996 
11:52:34 -0500 (CDT) 

Received: from ppp169.n2.net (ppp169.n2.net [204.250.22.169]) by ravel.n2.net 
(8.6.12/8.6.12) with SMTP id JAA12650 for <hfsig@tapr.org>; Thu, 25 Jul 1996 
09:54:29 -0700 

Date: Thu, 25 Jul 1996 09:54:29 -0700 

Message-Id: <199607251654. JAA12650@ravel.n2.net> 

X-Sender: k6sti@mail.n2.net 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: k6ésti@n2.net (Brian Beezley) 

Subject: Re: [HFSIG:1379] Re: HF bandwidth 


>I guess it's not surprising to encounter resistance on this. John 
>Costas wrote his paper "Poisson, Shannon and the Radio Amateur" way 
>back in 1959, and it was already obvious that it was going to be a 
>hard sell. The old ways due hard... 

> 

>I have much more to say later, but I wanted to make one quick point. 


>The central limit theorem from mathematics says that the sum of a 
>sufficiently large number of independent signals approximates a 

>Gaussian distribution. The characteristics of the individual signals 

>is surprisingly irrelevant, as long as they're independent. Even more 
>surprising is just how quickly it kicks in; just a few independent 
>sources are enough to make things look very Gaussian. 

> 

>As an aside, this explains why Gaussian noise is so common in nature. Most 
>natural sources of noise consist of a very large number of independent 
>processes that may or may not be Gaussian. A single drop of water splashing 
>on the beach doesn't sound very Gaussian, but the crashing surf does. 

> 

>So my quick point is this: how do you *xknowx that your link is limited 

>by natural background noise? How can you distinguish that from the din 

>of QRM from many distant background stations? 

> 

>Phil 

> 

> 

> 


The background noise I hear doesn't increase when the band opens. 


More than that, I think it takes the superposition of hundreds of amateur 
signals before the sound approaches that of white noise. I base this on my 
experience at the receiving end of big CW and SSB pileups. On only one 
occasion did a pileup ever begin to sound white. This was during a 
six-meter opening into Japan at the peak of the last cycle when I was the 
only US station being heard. I remember the incident well because I knew 
about the Central Limit Theorem at the time, had never heard it in action on 
the ham bands, but realized it probably explained why the pileup was 
beginning to sound like noise. A station in Guam played back the 6m 
frequency to me on 10 meters so I could hear what it sounded like close to 
Japan. From there it sounded like a huge pileup of individual SSB stations. 
Even though for a short while the pileup sound became somewhat noisy, I 
could still hear individual stations pop up and was able to work them. 

There was no way you could mistake the phenomenon for natural noise. I've 
never experienced a similar sound on HF, even while monitoring the massive 
pileups that occur when new countries come on the air for the first time. 
I'd be amazed if any of the noise I hear on HF is due to the superposition 
of weak stations. However, I think your conjecture is fascinating and I'm 
going to ask several DX-contest operators I know who have years of 
experience dealing with big pileups and see what they can tell me. 


73--Brian, K6STI 
k6sti@n2.net 


From forrerj@peak.org Thu Jul 25 12:44:06 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id MAA20267 for <hfsig@tapr.org>; Thu, 25 Jul 1996 
12:44:05 -0500 (CDT) 


Received: from p00.tO.monrotel.com (p00.tO.monrotel.com [198.68.25.33]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id KAA24655 for <hfsig@tapr.org>; Thu, 25 Jul 
1996 10:44:19 -0700 

Message-Id: <199607251744 .KAA24655@PEAK.ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Thu, 25 Jul 1996 10:31:15 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer ) 

Subject: Re: [HFSIG:1378] Re: Alexander wrote.. 


Hello Bob, 


> 

>There is enough detail in the articles for you to get the waveforms and 
>how they handle crest factor problems (I believe they ignore it and allow 
>interleaving and FEC fix it). The handshake protocol is what I meant by 
>upgrade/downgrade channels. 

> 

>Bob 

> 

> 


Yes - you are right of course about the basic quadrature sine/cosine 
components, the other thing that I mean is which bit/dibit/tribit to phase 
transition allocations were used and how bit/dibit/tribits are encoded from 
the bit stream. Any number of allocations would be possible. Is there any 
form of interleaving, for instance. If so, what depth. Without these basic 
details I have some difficulty to reproduce the waveform from a data stream. 
Perhaps you could share some insight. 


I found the reference to the tone spacing; it's 200 Hz or 2*T. As as you 
said seems like nothing is done about crest factor control. I do remind 
folks to check the earlier discussion here on HFSIG regarding interchannel 
interference when dealing with this kind of pulse shaping. 


Besides missing the handshaking protocol, what about the frame makeup? We 
also need to know what control information there is, where it is located, 
and how it's encoded. 


I also am a little ignorant about the compression scheme - I know the basic 
principle, and implemented the Huffmann compression of Pactor I. That 
required a table, which SCS kindly provided. But with Pactor II, I'm not 
sure what goes. Is Psuedo-Markov compression a dynamic scheme, i.e., 
building the table on the fly, like LZW, or is it some proprietary scheme 
that again uses their own tables. Without knowing how this works, it may as 
well be encrypted data. 


Pactor II is, in my opinion, a really advanced system, well thought out, and 
has a lot of potential. I must compliment the designers. I still ama bit 
puzzled by all the controversy, half truths, and ignorance of the real 


issues that is being said and propagated as facts. That, perhaps is human 
nature. On the other hand, it is great to see all the activities and 
excitement about digital technology - is'nt it great! 


--Johan 


From alanb@polecat.sr.hp.com Thu Jul 25 13:39:02 1996 

Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by tapr.org 

(8.7.5/8.7.3/1.9) with ESMTP id NAA22843 for <hfsig@tapr.org>; Thu, 25 Jul 1996 

13:38:55 -0500 (CDT) 

Received: from srmail.sr.hp.com by relay.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA159899931; Thu, 25 Jul 1996 11:38:52 -0700 

Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA139289929; Thu, 25 Jul 1996 11:38:51 -0700 

Received: by polecat.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AA222059928; Thu, 25 Jul 1996 11:38:48 -0700 

From: Alan Bloom <alanb@polecat.sr.hp.com> 

Message-Id: <199607251838.AA222059928@polecat.sr.hp.com> 

Subject: Spread Spectrum on HF 

To: hfsig@tapr.org 

Date: Thu, 25 Jul 1996 11:38:48 -0800 (PDT) 

X-Mailer: ELM [version 2.4 PL21] 

Mime-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 


Phil Karn <karn@qualcomm.com> wrote: 


>>The noise floor on 20m is about -120 to -110 dBm in a 3kHz bandwidth 
>>using an isotropic antenna. 3 dB degradation can make or break a DX 
>>contact so interference must be -120dBm or lower. 

> 

>How often is noise (by which I assume you mean natural background 
>noise) the limiting factor on 20m? As compared to QRM? 


>>Pathloss at 1km is 55dB for freespace, and probably around 70dB given 
>>real ground effects (into the same isotropic rx antenna, since only 
>>relative RX levels are important - unless you antenna is really bad). 
> 

>How many serious 20m DXers use isotropic antennas? Wouldn't it be more 
>reasonable to consider the front-to-back and front-to-side ratios of 
>typical 3-element yagis? 


It doesn't matter. Look, a decent communications receiver has over 

100 dB of dynamic range. Reduce that by 20 dB to account for atmospheric 
noise and background interference. That means the receiver can handle 

an out-of-band interfering signal 80 dB above the effective noise level. 
A direct-sequence spread spectrum transmitter 300 kHz wide will have 1% 
of its power in the receiver's 3 kHz bandwidth. So an interfering SS 
signal can be only 20 dB above the noise level if it is not to cause 
interference. That's 60 dB worse than for narrowband modes. 


>Only direct sequence spreads its power into a uniform, noiselike 
>distribution. 

>With a hopping rate of 20 Hz, one would expect, on average, to 
>hit every 1280 Hz channel once every 273/20 = 13.7 seconds or so. 


That's assuming the receiver frequency is exactly aligned with the 
transmitting channels. If the receiver straddles two transmit channels, 
the hit rate is twice as often. It also assumes a receiver bandwidth 
of 1280 Hz. Normal SSB receivers have about twice that bandwidth. 

The hit rate would be more like once every 4 or 5 seconds, which I 
personally would find very annoying. If there are several SS signals 
on the band, the hit rate would be totally unacceptable. 


>For a narrower target (such as a 400 Hz CW 

>filter, which I assume you'd be using if you're really seriously 
>working such weak DX), the hit rate would be proportionately longer: 
>once every 43.75 seconds. 


How do you figure? Even if the receiver bandwidth were 1 Hz, it would 
still get hit once every 13.7 seconds. Narrower bandwidth does lower 
the level of the interference, however. 


>Bear in mind that the commonly expressed objections to spread spectrum 
>deal solely with the near-far problem. First of all, I just don't 
>accept that near-far is unique to spread spectrum, as anybody who has 
>ever lived next door to another active ham knows very well. Sine waves 
>are absolutely perfectly orthogonal only in theory. Real filters 
>aren't perfect, real power amplifiers produce intermodulation 
>distortion, and real VCOs produce phase noise. 


That's all true, and one could argue whether the interference advantage 
of narrow-band modes is really 60 dB or some other number, but it's 
still a huge advantage. (Actually, I think the 80 dB effective receiver 
dynamic range number I used is, if anything, conservative.) 


>And third, given the widespread use of spread spectrum, any occasional 
>increase in QRM to a narrowband receiver from a nearby SS station 
>will, on average, be more than made up for by a significant xdecreasex 
>in total interference from distant stations, thanks to the increased 
>power efficiencies SS makes possible. 


Dynamic power control can be used just as easily with narrowband digital 
modes as with broadband spread spectrum. 


>In practice, almost 
>every real HF link is ultimately limited by the din of QRM from many 
>distant stations reusing the same channel. 


>The central limit theorem from mathematics says that the sum of a 
>sufficiently large number of independent signals approximates a 


>Gaussian distribution. 


>A single drop of water splashing 


>on the beach doesn't sound very Gaussian, but the crashing surf does. 


>So my quick point is this: how do you xknowx that your link is limited 
>by natural background noise? How can you distinguish that from the din 
>of QRM from many distant background stations? 


That's an interesting theory. You're saying that what we perceive as 
atmospheric noise is in reality thousands of weak distant signals added 
together. I admit that there have been times when I have heard thousands 
of weak signals added together (in contests and in pileups), and it indeed 
does eventually start to sound a lot like random noise. However, the ear 
has no trouble distinguishing it from Gaussian noise. 


In any case, it doesn't affect the conclusion of the argument. Whatever 
the background noise level, a strong spread spectrum signal on 20 meters 
will raise the effective noise something like 60 dB more than a narrowband 
signal of the same power. 


AL N1AL 


From Robert.Glassey@nmp.nokia.com Thu Jul 25 13:43:54 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id NAA23114 for <hfsig@tapr.org>; Thu, 25 Jul 1996 
13:43:51 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id VAAQ5096 for <hfsig@tapr.org>; Thu, 
25 Jul 1996 21:43:18 +0300 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AA244440005; Thu, 25 Jul 1996 21:40:05 +0300 
X-Openmail-Hops: 2 
Date: Thu, 25 Jul 96 19:40:53 +0100 
Message-Id: <H0000292021d84b2@MHS> 
In-Reply-To: <199607250028.RAA09259@servo.qualcomm. com> 
Subject: [HFSIG:1370] Re: HF bandwidth 
Sender: Robert.Glassey@nmp.nokia.com 
To: hfsig@tapr.org 


Hi Phil, 


Thanks for the reply. I'm not trying to flame here, but only to express 
the concerns I and many other hams have, and to try to look at the 
detail to address these concerns. 


> How often is noise (by which I assume you mean natural background 
> noise) the limiting factor on 20m? As compared to QRM? 


Where DX is concerned QRM is not the limiting factor, since you can 
usually find a clear frequency. Reducing QRM is certianly a good aim, 


and if the QRM'er were using less power or spreading wider, then that 
QRM would be lower, but if everyone spread wider then the local guys 
would be the problem, not the DX QRM - clasic near far problem. As my 


analysis shows its the local guys QRM that is the limiting factor. 


One intresting point hidden in your comment is the effect of fading, 
which I would consider more significant than DX QRM. As I understand it 
spreading can reduce data lost to fading. Even using only 2.4kHz there 
appears to be an advantage here. Still there are a lot less 2.4kHz 
channels for local hams to use. ('local' stations must be on differenct 
frequencies if the 1 microwatt syndrome is to be ovoided) There may be 
sufficent bandwidth for local operators to use 2.4kHz channels, and this 
may well have the DX QRM reducing advantages you mention. And the more 
efficent the modulation the lower the average TX power, so the fewer 
‘local' stations there are to share channels. There does appear to be a 
limit however, based on propagation conditions, average DX distances, 
and number of opertors. 


>Pathloss at 1km is 55dB for freespace, and probably around 70dB given 
How many serious 20m DXers use isotropic antennas? Wouldn't it be more 
reasonable to consider the front-to-back and front-to-side ratios of 
typical 3-element yagis? 


VVV NV 


For simplicity of analysis isotropic antennas were assumed. Where 
directional antennas are used the average interference level from DX 
stations does decrease, however we are concerned about the local noise 
floor, and a directional antenna at best would only give 20dB rejection, 
and at worst could give several dB gain! In the local enviroment 
averages don't work. Worst case must be assumed here, since it is the 
worst case that will cause problems. 


>regardless of the spreading method. (assuming power is evenly 
>spread) . 


Ah, but it xdoesx depend on the spreading method. Only direct sequence 
spreads its power into a uniform, noiselike distribution. Consider 
instead a medium-rate M-ary FSK system like I propose. Pick a symbol 
duration on the order of 50ms (20 Hz). A 64-ary scheme would therefore 
require 64x20=1280 Hz at any given instant. Now let's frequency hop on 
every symbol over the 350 KHz of the 20m band. 350 Khz/1280 Hz ~= 

273. With a hopping rate of 20 Hz, one would expect, on average, to 
hit every 1280 Hz channel once every 273/20 = 13.7 seconds or so. (If 
the hopping pattern were a linear frequency chirp, this would happen 
exactly periodically). For a narrower target (such as a 400 Hz CW 
filter, which I assume you'd be using if you're really seriously 
working such weak DX), the hit rate would be proportionately longer: 
once every 43.75 seconds. And each "hit" would last just 50ms. 


How often do fades occur on 20m? Static crashes? Intermittent QRM 
from key-down VFO spotting, key clicks, SSB spillover and "didit-dit" 
queries? Less often than once per 45 seconds? How long do they last? 
Shorter than 50ms? 


Keeping everything else constant, yes, the average interference power 
is the same for frequency hopping as for direct sequence. But I 
suspect that most narrowband operators would find strong QRM a small 


VV VV VV VV VV VV VV VV VV VV VV VV WV 


> fraction of the time to be less objectionable than continuous, 
> low-level QRM (continuous at least when transmitting) . 


Some good points also. We appear agreed that direct sequence is 
definately out. Hopping clicks are definatly more acceptable. 


CW 44 seconds between clicks with a good filter 
1280data 14 seconds 
SSB 7 seconds 


Of course the more stations the more clicks. With power control & ECC 
(simply keeping power down to minimum usable levels) the strength of 
each user will be lower, say on avreage 10-20dB lower. When each user 
becomes a click, how strong and how many clicks will their be? 


Say there's 1 other local station, with power control S9+30dB, 5 strong 
stations, S9 with power control 20 weaker stations, s1-s5 with power 
control. You are working a S1 signal since he has reduced his power to 
the minumum level. You are loosing about 10% of the data. No too bad, 
with ECC. 


An SSB station would hear roughly a click a second, with a bit of faster 
background clicking. Not nice, but modern noise blankers can handle this 
type of noise exceptionally well. 


As the bands become more conjested data loss become more significant, 
especially for modes with little error correction. RTTY, amtor, pactor, 
packet, would become useless. It may be better to stick to SSB only 
portions of the band. 


It would help to study the behavior of typical HF transceivers when 
designing such a modulation scheme. How do their AGCs respond to very 
short bursts of a strong signal? How about their now-unused 
"woodpecker" filters, could they be used to blank a somewhat shorter 
symbol time altogether? Shorter M-ary symbols would probably be 
preferable anyway, to increase the user data rate. 


VV VV VV 


Interesting that you comapre this proposed mode to the ‘woodpecker'. It 
took a massive international effort to get rid of the much hated 
woodpecker (and massive political changes), this is *very* dangourous 
territory. If hams use a woodpecker like mode, then the ham bands become 
fair game for the next generation of over the horizon, space weapon 
resistant radars. 


Bear in mind that the commonly expressed objections to spread spectrum 
deal solely with the near-far problem. First of all, I just don't 
accept that near-far is unique to spread spectrum, as anybody who has 
ever lived next door to another active ham knows very well. Sine waves 
are absolutely perfectly orthogonal only in theory. Real filters 
aren't perfect, real power amplifiers produce intermodulation 
distortion, and real VCOs produce phase noise. 


VV VV VV MV 


Very true, however TX intermod is limited to a few kHz of the signal, 


and crystal filters have a lot more rejection than any amount of 
procesing gain will give you. The last time I had problems with a local 
transmitter was when I was using a 1968 vintage FTDX400, which had 
fairly poor first IF selectivity and a S9+60dB CW signal was able to 
modulate the AGC. This is many orders or magnitude better than SS 
systems, where 1 watt at 10 miles can render the entire band useless. 


Second, there are other effective ways to mitigate the near-far 
problem beyond what I've already described, such as designating DX 
subbands and excluding them from the frequency hopping list. Having 
subbands for "DX", "local", "regional" and the like -- without regard 
to mode -- makes far more sense than our present scheme of dividing 
them up by emission mode. And that's not just because modern 
technology is hopelessly blurring the distinctions between "voice", 
"image" and "data". 


VV VV VV VV 


This would go some of the way, but if two DXers were active in the same 
area band segragation would not help. Some form of carrier sense would 
also help, but we all know how poorly that works on HF packet. 


And third, given the widespread use of spread spectrum, any occasional 
increase in QRM to a narrowband receiver from a nearby SS station 
will, on average, be more than made up for by a significant xdecreasex 
in total interference from distant stations, thanks to the increased 
power efficiencies SS makes possible. As crowded as the HF bands are, 
it is rare to find an HF link truly limited by thermal or natural 
noise -- except perhaps when the band is closed. So postulating that 
limit in a SS QRM analysis is simply unrealistic. In practice, almost 
every real HF link is ultimately limited by the din of QRM from many 
distant stations reusing the same channel. 


VV VV VV VV VV 


And that's what makes it in the direct interest of the narrowband user 
that power-controlled spread spectrum become as widespread (!) as 
possible, because that's the only way to reduce the total amount of RF 
power floating around as background QRM. 


VV VV 


I understand your arguments here, although I think 90% of the gain here 
can come from automatic power control and robust modem protocols alone. 
Ovoiding nasty near-far/woodpecker problems altogether, that would 
really be an advantage to narrow mode users. 


SUMMARY... ish 


You have presented quite a few excelent points, furthering the 
understanding of these techniques in at least the technical ham 
community. They're much appreciated by all I'm sure. The first step in 
promoting an understanding of these principles is open discussion, 
questions and answers in technical forums like HFSIG. Many thanks! 


I think we are both agreed that Direct Sequence spread spectrum is 
inappropriate on HF. And I'll admit many of my objections were based on 
the assumption of some form of even power spreading. 


It think the single most important point you have made is the difference 
between direct sequence and hopping. Namely that even strong pulse 
interference can be removed with impulse noise blankers and a neighbours 
SS system will not kill yours regardless of the power he runs (within 
reason). This dramatically improves the situation, and practically 
eliminates the local near far problem. Near-far may still be a problem 
when the bands are conjested since the many nearer dx stations will 
swamp the farther ones. Hmmm, but if eveyone is running low power, the 
few long distance DXers can increase their power without seriously 
effecting the nearer low power stations working shorter distances. 
however if many people worked long DX then short DX stations would have 
to increase their power to compensate. But hopping certianly is much 
better than direct sequence due to the its non-linear nature. 


However we now have 'woodpecker' type interference on the band. The more 
stations the worse it gets. On SSB, noise blankers can remove the 
interference, however older digital modes with no ECC will suffer 
greatly due to lost bits, and rappidly reach the point where they are 
unusable. One solution to this is to only spread over the SSB part of 
the band. 


Reducing average QRM is a very worthy aim. However much can be gained 
here with automatic power control and more power efficent modulation and 
coding schemes. Manual ovoidance of most QRM is possible. 


Spreading is a double edged sword. It may allow more power efficent 
systems through its ability to overcome fadeing, although you can 
probably get significant gain with a small degree of spreading (2.4kHz 
or a bit more) but after that we may be into deminishing returns here. 


Spreading wider does reduce the rate of clicking, but the resulting 
increase of stations in the same band will increase the clicking rate 
again. If there is a gain here it will be in the more even distribution 
of click strengths. 


On the other hand a woodpecker effect will be strongly resented, 
especially by home brew enthusiests who may resent having to build a 
noise blanker with no net gain to themselves, so a few data users can 
have their 'antisocial' mode. The woodpecker was a much hated 
interference source and removing the woodpecker from the HF bands was a 
major achievement. Going back to the bad old days would be strongly 
opposed. Remember we are no longer talking of below the noise 
interference, this is very real 24 hour s9+ woodpecker interference for 
only a small benifit (over narrow spreading) for the few HF-SS data 
operators, that everyone else must live with, in the name of ‘less 
interference’ 


So it seems hopping is vastly better than direct sequence but still 
antisocial. And the aims of reduced QRM are well worthwhile, but the 
question we should be asking is how much do we need to spread to get a 
significant QRM reduction, and what is the trade off with the annoyance 
factor of the woodpecker effect? 


Are narrow modes with power control sufficent? Will this reduce QRM 
enough? The advantage here is we annoy nobody! 


How about 2.4kHz spreads? How many extra dB's do we gain over narrow 
modes here. Is it worth taking up 5 times the bandwidth, in terms of 
other users and their rights to spectrum as a proportion of total users? 


Can we go further and take say the top 50 or 100kHz and spread over 
that, how many toes will that step on? Is it feasible in a cooperative 
and friendly band sharing service like amateur radio? How many extra dB 
do we really gain here, in terms of QRM reduction? Is it worth it? 
Maybe if it really does work in practice this would be the way to start 
out, small at first without challanging to many people and making them 
turn defensive. 


Does spreading over the entire band really have such a dramatic 
improvement that all amateurs should be forced to accept this new 
thinking, dramatically changing the outlook and practice of amateur 
radio forever? Can the amateur service not survive without it? Or is it 
so good that everyone will be falling over themselves to get onto this 
new mode to ovoid the QRM of the older modes, something like the AM to 
SSB switch? Even if this miricle does occur, surely operators must 
decide for themselves that the switch is what they want. Amateur radio 
is not a dictatorship. This makes a whole band (or most of the band) SS 
mode a thing of the distant future, with smaller SS sub-bands being the 
direction for now if even they are justified. 


If it really does work, and if the international authorities can be 
convinced, maybe we could get a NEW BAND. This would keep everyone 
happy! Lots of good PR opertunities there, and it would encourage people 
to give it a go, without threatening existing modes and bands. 


Sorry this is so long, but there are a lot of issues here and a lot to 
get my mind around. 


Rob 


From LANIER.R.A-@smtpgty.bwi.wec.com Thu Jul 25 14:16:37 1996 
Received: from tron.bwi.wec.com (tron.bwi.wec.com [129.228.4.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id OAA24685 for <hfsig@tapr.org>; Thu, 25 Jul 1996 
14:15:53 -0500 (CDT) 
Received: from smtpgty.bwi.wec.com by tron. bwi.wec.com; 
(5.65/1.1.8.2/31May95-0229PM) 
id AA26376; Thu, 25 Jul 1996 15:13:40 -0400 

Received: from ccMail by smtpgty.bwi.wec.com 

(IMA Internet Exchange 2.0 Enterprise) id 1F7C79CO; Thu, 25 Jul 96 15:14:36 
-0400 
Mime-Version: 1.0 
Date: Thu, 25 Jul 1996 13:49:10 -0400 
Message-Id: <1F7C79C0.1858@smtpgty .bwi.wec.com> 
From: LANIER.R.A-@smtpgty.bwi.wec.com (LANIER.R.A-) 
Subject: Re: [HFSIG:1377] Re: HF bandwidth 


To: hfsig@tapr.org 

Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


The only arguement I can find valid for having SS in the upper bands 
(UHF+) is for a wider spread bandwidth. I STILL haven't heard a valid 
arguement AGAINST SS only that so many people think that SS will 
"raise the noise floor." If every ham will use SS, maybe, but I 
contend this will never happen. I estimate the number of hams using 
this modulation scheme might grow to possibly 10%. And that's being 
liberal with the figures. Lets encourage SS experimentation, and IF 
interference occurs, THEN lets do something about it. Only until we 
have conclusive interference tests will this issue be put to rest. 


73s de 
Tony, KE4ATO 


[Ne dag te abt a 2 Ene oe 2 ee ed Reply Separator 
Subject: [HFSIG:1377] Re: HF bandwidth 

Author: hfsig@tapr.org at BALT.SMTP 

Date: 7/25/96 5:36 AM 


Phil wrote: 

Based on my experience so far promoting the ARRL proposal for more 
liberal spread spectrum rules, I'm skeptical. Everyone keeps screaming 
about "raising the noise floor", and they don't accept arguments that, 
on average, the noiset+interference floor would actually be xlowerx on 
a crowded band with power controlled spread spectrum than with our 
present uncontrolled narrowband techniques. 


VVVVV WV 


Sorry to be a pain Phil, but I havent seen any such arguments, I've only 
seen SS proponents making bold and unsupported claims while the laws of 
physics appear to dissagree with them. 


The basic SS argument makes several invalid assumptions: 


1/ The bands are so conjested that DX is impossible, and QRM is the 
limiting factor in amateur communications. 


2/ That cooperative, effective power contorl is possible on a global 
scale, both technically (near far problems) and politically. 


3/ That nobody else in your neighbourhood will be transmitting or 
receiving on the same band as you to anyone further than the 
distance between you and your neighbour. The clasic near-far 
problem. 


4/ That all hams prefer local celular type communications to DX. 


5/ That all hams want to operate only one mode. Namely SS. 


I'm actually in favour of SS, but only where appropriate, ie above 2GHz, 
in exclusive SS bands maybe 10 to 100MHz wide, in a celular style high 
speed random access HAM-LAN digital network. I think you would find a 
lot of support for this, inspiring enthusiastic developemnt, but on HF 
you'll always be swimming against the current, fighting a loosing 
battle, where either you or ham radio in general must loose. 


Sorry to be such a spoil sport, lets get back to more realistic HF 
modems and developing an open standard for the next generation of ham 
friendly HF data modems. 


More on standards later.... 
Cheers, 


Rob 


From kchen@apple.com Thu Jul 25 15:19:19 1996 

Received: from apple.com (apple.com [130.43.2.2]) by tapr.org (8.7.5/8.7.3/1.9) 
with SMTP id PAA28585 for <hfsig@tapr.org>; Thu, 25 Jul 1996 15:19:17 -0500 (CDT) 
Received: from 17.214.12.145 (A17-214-12-145.apple.com [17.214.12.145]) by 
apple.com (8.6.12/8.6.12) with SMTP id NAA21946 for <hfsig@tapr.org>; Thu, 25 Jul 
1996 13:19:14 -0700 

Message-ID: <31F7D710.2081@apple.com> 

Date: Thu, 25 Jul 1996 13:20:32 -0700 

From: Kok Chen <kchen@apple.com> 

Reply-To: kchen@apple.com 

Organization: Apple Computer, Inc. 

X-Mailer: Mozilla 2.02 (Macintosh; I; 68k) 

MIME-Version: 1.0 

To: hfsig@tapr.org 

Subject: [HFSIG:1381] Re: HF bandwidth 

Content-Type: text/plain; charset=us-ascii 

Content-Transfer-Encoding: 7bit 


Interesting discussion regarding spread spectrum. 


I side with K6STI and a few others here in questioning whether 
SS and narrow-band (compared to SS, even AM is narrow-band :-) 
modes can coexist within the same sub-band. 


One also has to be careful how one applies Central Limit Theorem, 
and further, remembering that it is the probability density function 
of a random process we are talking about and not its frequency 
spectrum. So, just because crashing surf sounds white, it may well 
not have Gaussian pdf. 


A lot of us are probably familiar with a very common usage of 

CLT, viz, that of adding 12 random numbers from a uniformly 
distributed pdf, the result being an amazingly good approximation 
of a random number with a Gaussian (normal) distribution function. 


The magical 12 is especially pleasing since the resultant standard 
deviation is precisely 1, starting with twelve unity width uniform 
distributed random numbers. 


But, wait a minute. Let's see what happens if we start with twelve 
random numbers whose standard deviation ("RMS magnitude") are not 
identical. Let's say one of the twelve is 10 dB "louder" than the 
other eleven. The result is easy to visualise (since the pdf of 
the sum of a set of random numbers is precisely the convolution 

of the pdfs among themselves; no kidding, go look at the equations 
involved) and is distinctly non-Gaussian. Indeed, the resultant 
pdf will be shaped sort of like a raised rectangle, whose rising 
and trailing edges are "gaussian" in "shape." What if the odd 
signal is 20 dB "louder"? Gosh, the resultant pdf is almost the 
same as the pdf of that loudest signal. 


This makes the real world very ugly. Let's say there is a chap 
who lives a few blocks from you. He runs SS and puts an S9+20dB 
signal into your receiver. Forget all the white Gaussian noise 
arguments, your evening of DX'ing is ruined (may your AGC [and 
your ear drums] recover fast enough from that hypothetical 50ms 
burst, HI). 


The corollary is that if you have a neighbour like this, you will 
need a zillion other S2 or S3 spread spectrum signals to be in the 
same passband before that part of the sub-band obeys all the nice 
theoretical properties. At the point when that happens, it doesn't 
matter anyway; the theoreticians are now kept happy, but you will, 
at that point, have an S9 noise from band edge to band edge! 


The question is going to be, do I want to always have QRM in 10% 
of all my QSOs, or have 1 out of 10 of my QSO's containing QRM. 
Especially when, in the latter case, I could always QSY (well, 
not if the other fellow is VKOWH, I guess :-) in the one out of 
ten cases, and end up with no QRM. 


73 


Kok Chen, AA6TY kchen@apple.com 
Apple Computer, Inc. 


From k6sti@n2.net Thu Jul 25 17:43:07 1996 

Received: from ravel.n2.net (ravel.n2.net [204.250.22.20]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id RAAQ6285 for <hfsig@tapr.org>; Thu, 25 Jul 1996 
17:43:03 -0500 (CDT) 

Received: from ppp176.n2.net (ppp176.n2.net [204.250.22.176]) by ravel.n2.net 
(8.6.12/8.6.12) with SMTP id PAA29512 for <hfsig@tapr.org>; Thu, 25 Jul 1996 
15:44:58 -0700 

Date: Thu, 25 Jul 1996 15:44:58 -0700 

Message-Id: <199607252244 .PAA29512@ravel .n2.net> 

X-Sender: k6sti@mail.n2.net 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 


Content-Type: text/plain; charset="us-ascii" 
To: hfsig@tapr.org 

From: k6ésti@n2.net (Brian Beezley) 

Subject: Noise Blankers 


>An SSB station would hear roughly a click a second, with a bit of faster 
>background clicking. Not nice, but modern noise blankers can handle this 
>type of noise exceptionally well. 


I don't think any HF-modem scheme should rely on the use of common noise 
blankers. As anyone who has had occasion to use one on a crowded HF band 
knows, they are extremely susceptible to strong signals outside the narrow 
IF filter passband but within the somewhat wider roofing filter passband. 
The peaks of strong signals activate the blanker and devastate the received 
audio. I use my TS-930S noise blanker only when absolutely necessary. 
Often I'd like to engage it but can't. 


Some VHF hams use homebrew blankers that sample RF outside the ham band in a 
region with no signals. The blanker in one Collins HF receiver also sampled 
noise pulses in the VHF range. But these kinds of blankers aren't common. 


73--Brian, K6STI 
k6sti@n2.net 


From karn@qualcomm.com Thu Jul 25 23:42:19 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id XAA21794 for <hfsig@tapr.org>; Thu, 25 Jul 1996 
23:42:17 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
VAA24460; Thu, 25 Jul 1996 21:41:46 -0700 (PDT) 

Date: Thu, 25 Jul 1996 21:41:46 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607260441.VAA24460@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199607252244.PAA29512@ravel.n2.net> (k6sti@n2.net) 

Subject: Re: [HFSIG:1387] Noise Blankers 


Whether a noise blanker helps or hurts a digital modem probably 
depends on the specific situation. The most important thing is that 
the receiver recover as quickly as possible after any strong burst of 
interference, be it a wideband radar pulse or a relatively narrow 
signal. What it does xduringx the pulse is less important. And it is 
very important that any NB not kick in when there is no pulse. 


In a radio with a slow decay AGC, a noise blanker is a big help by 
removing much of the pulse energy that would otherwise reach the AGC. 
This is especially true with 70cm military radar. 


An alternative is to just turn off the AGC so pulsed QRM can't affect 
it. If dynamic range is a problem, let the demodulator control the 


gain somehow, perhaps by driving a DAC wired back into the 

radio. Since the demod has a better knowledge of what the desired 
signal looks like than the radio does, it can do a better job of 
setting the RX gain without being fooled by strong QRM. 


Of course, to deal with impulse QRM, any modem will have to have good 
coding and interleaving, as no blanker can actually restore what's 
covered by a strong noise pulse. 


What is normally thought of as the main function of a noise blanker, 
muting the audio output during the noise pulse, is not so important 
here. The modem can do this for itself if it has to. A hard-decision 
FEC decoder probably won't care; the pulses simply cause errors that 
the decoder has to correct. 


A soft-decision Fano or Viterbi decoder has to take more care. You 
don't want a strong noise pulse to mimic a data symbol with a very 
strong (good) metric. You probably want to treat any burst of symbols 
that's suddenly well above the average signal level as "outliers" and 
erase them before decoding. 


Phil 


From karn@qualcomm.com Fri Jul 26 03:53:59 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id DAAQ6282 for <hfsig@tapr.org>; Fri, 26 Jul 1996 
03:53:57 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
BAA25081; Fri, 26 Jul 1996 01:53:25 -0700 (PDT) 

Date: Fri, 26 Jul 1996 01:53:25 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199607260853 .BAA25081@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <31F7D710.2081@apple.com> (message from Kok Chen on Thu, 25 Jul 1996 
15:42:48 -0500 (CDT)) 

Subject: Re: [HFSIG:1386] Re: HF bandwidth 


>One also has to be careful how one applies Central Limit Theorem, 
>and further, remembering that it is the probability density function 
>of a random process we are talking about and not its frequency 
>spectrum. So, just because crashing surf sounds white, it may well 
>not have Gaussian pdf. 


Sure, the sum of a bunch of independent narrowband processes will 
approximate a narrowband Gaussian. The linear summing process can't 
create frequency components that weren't in the original signals. But 
the result *xwillx look like noise, at least over a limited bandwidth. 


In the real world of course, stations are scattered all over the band, 
and many will overlap. So the ultimate limit in a very crowded band is 


Gaussian noise that's bandlimited to the entire band. 


And yes, you're right that if one source has a much larger variance 


(power) than all the rest, it dominates the sum. 


My point was just to get people thinking about the equivalence between 
noise and interference. AS a spread spectrum guy I already think that 
way, but many of the same rules apply to ensembles of narrowband 
signals. 


You xhavex to start thinking average and not worst case. If you insist 
on the worst case game, then I could concoct a much worse worst case 
for narrowband by assuming I put xallx of my power into your channel 
as QRM, rather than just part of it. :-) 


What matters in the end on a crowded band is the total interfering 
signal power summed over all of the stations and not their individual 
bandwidths. So to the extent that spread spectrum allows the use of 

less average signal power by each station (thanks to FEC coding gain 

plus the power savings from the extra frequency diversity in Rayleigh 
fading), there will be less background QRM even for the narrowband users. 


More later, I'm off to the Central States VHF Society conference in 
a few hours, and I need sleep... 


Phil 


From Robert.Glassey@nmp.nokia.com Fri Jul 26 04:23:28 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id EAAQ6920 for <hfsig@tapr.org>; Fri, 26 Jul 1996 
04:23:26 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id MAA10977; Fri, 26 Jul 1996 12:22:19 
+0300 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AA258872742; Fri, 26 Jul 1996 12:19:02 +0300 
X-Openmail-Hops: 2 
Date: Fri, 26 Jul 96 10:19:12 +0100 
Message-Id: <H0000292021f£32e2@MHS> 
In-Reply-To: <199607260441.VAA24460@servo.qualcomm. com> 
Subject: [HFSIG:1388] Re: Noise Blankers 
Sender: Robert.Glassey@nmp.nokia.com 
To: hfsig@tapr.org, karn@qualcomm.com 


> An alternative is to just turn off the AGC so pulsed QRM can't affect 
> it. If dynamic range is a problem, let the demodulator control the 
Phil wrote: 


gain somehow, perhaps by driving a DAC wired back into the 

radio. Since the demod has a better knowledge of what the desired 
signal looks like than the radio does, it can do a better job of 
setting the RX gain without being fooled by strong QRM. 


VV VV 


Yes, I agree. looking forward to when we have more digital receivers, 
AGC controlled by the demodulator would be an effective solution for 


these types of SS links. Error correction, which makes use of erasures 
would effectivly 'smooth over' the pulses (as seem in the data stream). 


The real problem is not the SS RX, but compatibility with the other 
modes used on the band, ie digital modes with little ECC, and SSB. 


Like I have mentioned, we cannot assume that all hams will want to use 
only one mode. Forcing this would be the death nail in amateur radio. 


Brian wrote: 


I don't think any HF-modem scheme should rely on the use of common 
noise blankers. As anyone who has had occasion to use one ona 
crowded HF band knows, they are extremely susceptible to strong 
Signals outside the narrow IF filter passband but within the somewhat 
wider roofing filter passband. The peaks of strong signals activate 
the blanker and devastate the received audio. I use my TS-930S noise 
blanker only when absolutely necessary. Often I'd like to engage it 
but can't. 


Some VHF hams use homebrew blankers that sample RF outside the ham 
band in a region with no signals. The blanker in one Collins HF 
receiver also sampled noise pulses in the VHF range. But these kinds 
of blankers aren't common. 


VV VVV VV VV VV VV 


Like Brian says, and I'd forgotton, impulse noise blankers rely on the 
noise being wideband. A hopping signal may not trigger the noise blanker 
when required, and may trigger when it should not (ie the pulse is 
outside the final filter, but inside the roofing filter - with a much 
higher hit rate too! And of course under conjested conditions these 
noise blankers may not work anyway. 


The 'Big Three' HF manufactureres would have to introduce a new spread 
spectrum pulse blanker, probably implimented in the the internal DSP 
units. Meanwhile the majority of hams using equipment of the 90's 
vintage and eariler would have to put up with it. 


Rob, GOVTQ 


From BRYD@KIDD.CO.ZA Fri Jul 26 06:58:45 1996 
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id GAA11539 for <hfsig@tapr.org>; Fri, 26 Jul 1996 
06:55:37 -0500 (CDT) 
Received: from KIDD.CO.ZA by igw01 with smtp 
(Smail3.1.29.1 #3) id mOuj1RV-OOOPFTC; Fri, 26 Jul 96 13:52 GMT+0200 
Received: from KenMail-Message_Server by KIDD.CO.ZA 
with Novell GroupWise; Fri, 26 Jul 1996 13:41:01 +0200 
Message-Id: <s1f£8caed.014@KIDD.CO.ZA> 
X-Mailer: Novell GroupWise 4.1 
Date: Fri, 26 Jul 1996 13:32:12 +0200 
From: Danie Brynard <BRYD@KIDD.CO.ZA> 
To: hfsig@tapr.org 
Subject: Rob just to confirm: can you send me a copy of btl to: 


zs6awk@global.co.za ? 
Rob just to confirm: can you send me a copy of btl to: zs6awk@global.co.za ? 
This other email of mine does not work well. 


danie 


From wd6ehr@kaiwan009.kaiwan.com Sat Jul 27 16:18:16 1996 
Received: from kaiwan009.kaiwan.com (kaiwan009.kaiwan.com [198.178.203.9]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA29145 for <hfsig@tapr.org>; Sat, 27 
Jul 1996 16:18:15 -0500 (CDT) 
Received: (from wd6ehr@localhost) by kaiwan009.kaiwan.com (8.7.3/8.7.3) id 
0AA23545 for hfsig@tapr.org; Sat, 27 Jul 1996 14:18:05 -0700 (PDT) 
*xk*x KAIWAN Internet *x* 
From: Mike Curtis <wd6ehr@kaiwan009.kaiwan.com> 
Message-Id: <199607272118.0AA23545@kaiwan009.kaiwan.com> 
Subject: List owner? 
To: hfsig@tapr.org 
Date: Sat, 27 Jul 1996 14:18:04 -0700 (PDT) 
X-Mailer: ELM [version 2.4 PL22] 
MIME-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 


Who is the listowner? Because my address has changed slightly (from 
kaiwan.com to kaiwan009.com), I am unable to make changes in my account. 


-- mike 


From Robert.Glassey@nmp.nokia.com Mon Jul 29 08:43:12 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id IAA27588 for <hfsig@tapr.org>; Mon, 29 Jul 1996 
08:43:09 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id 0AA11738 for <hfsig@tapr.org>; Mon, 
29 Jul 1996 14:59:28 +0300 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AA121631363; Mon, 29 Jul 1996 14:56:03 +0300 
X-Openmail-Hops: 2 
Date: Mon, 29 Jul 96 12:29:44 +0100 
Message-Id: <H0Q000292021eda1c@MHS> 
In-Reply-To: <199607230108.SAA05265@servo.qualcomm. com> 
Subject: SCS business stratagy 
To: hfsig@tapr.org 


Brian Wrote: 
>> But you didn't expend the resources to develop the algorithm. SCS 
>> tells me they spent a very long time researching and testing the 


>> protocol. When you do that, you can't afford to give the final 
>> result away. I'd love to implement Pactor II myself, but I can 
>> understand why licenses aren't being offered cheap. 


Phil wrote: 

Keeping the protocol proprietary isn't necessarily going to pay back 
their development costs either. The computer and communications 
industry has a long history of proprietary technologies being quickly 
displaced by more open, standard systems. Anybody here still use a 
Telebit Trailblazer modem in PEP mode? 


More enlightened companies are content to have part of something 
rather than 100% of nothing. 


VV VV VV VV 


I have to agree with phil. The industry I'm in is based on open 
standards and they are nessesary to allow the growth of this type of 
technology, and of course the growth of our company. And IBM is still 
one of the worlds largest suppliers of PC's! 


Developing a standard is a lot of work of course, but expecting to make 
the money back through selling a few licences at a high price may not be 
wise or in the companies best interests. There's probably very little in 
pactor II that we on HFSIG cannot duplicate without a licence. We may 
not be allowed to make a compatible modem, but we could make one just as 
good. If manufacturers, programers and ultimatly hams have a choice 
between an expensive propietry protocol in very limited use and a free 
open protocol thats just as good, then SCS may not be in a very good 
position. 


Delevoping (or being a major contributor) to a standard gives the 
developer a head start on the competition and allows them to taylor the 
protocol to suit them to some extent. It also allows them to stimulate 
and grow at market that they will be in an ideal position to exploit. 


The PTC II modem is very expensive, but then its a very complex bit of 
kit, and would make most PCs it would be used with look pretty lame. 
This box can 'pat its head and rub its belly at the same time while 
wistling Waltz Sing Mytilder'. It seems aimed at commercial and 
millitary users. Its not the sort of thing the average ham would have on 
his bench, you may use it in a BBS, given its dual port abilities, but 
how many hams would connect in pactor II. You'd bet better off getting 
two PK232MBX's. If SCS is serious about PACTOR II in the amateur 
enviroment is should make the standard open, or at least cheap, 
otherwise it may never become popular. Even if it does, every year lost 
is a years profits lost. SCS needs to bring out a cheap PACTOR II modem 
to be competitive in an open market and to make a profit and cover its 
developement costs though sales volumes. There is no reason why SCS 
cannot produce a competitive DSP232 like box with PACTOR II, that could 
become as much a standard as the PK232. This is a rapidly growing market 
and they could take a fair share with an open standard and the right 
products. 


Alternativly a few 'real' hams could develop an open standard, or adopt 


a MIL standard, and leave SCS in the lurch. 
Lets develop an open standard and get better, faster and cheaper modems. 
Rob 


From k5yfw@www.kelly-afb.org Mon Jul 29 10:32:14 1996 

Received: from www.kelly-afb.org (www.kelly-afb.org [204.214.204.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id KAAQ2839 for <hfsig@tapr.org>; Mon, 29 Jul 1996 
10:32:13 -0500 (CDT) 

Received: (from k5yfw@localhost) by www.kelly-afb.org (8.7.1/8.7.1) id KAA11287 
for hfsig@tapr.org; Mon, 29 Jul 1996 10:32:45 -0500 (CDT) 

From: Walt DuBose - K5YFW <k5yfw@www.kelly-afb.org> 

Message-Id: <199607291532.KAA11287@www.kelly-afb.org> 

Subject: Re: [HFSIG:1393] SCS business stratagy 

To: hfsig@tapr.org 

Date: Mon, 29 Jul 1996 10:32:45 -0500 (CDT) 

In-Reply-To: <H0000292021eda1c@MHS> from "Robert.Glassey@nmp.nokia.com" at Jul 29, 
96 08:54:33 am 

Reply-To: k5yfw@www.kelly-afb.org 

X-Mailer: ELM [version 2.4 PL24] 

Content-Type: text 


_BRAVO_ 


In your message you write: 

> Phil wrote: 

> Keeping the protocol proprietary isn't necessarily going to pay back 
> their development costs either. The computer and communications 

> industry has a long history of proprietary technologies being quickly 
> displaced by more open, standard systems. 


VVV NV 


Anybody here still use a 
> > Telebit Trailblazer modem in PEP mode? 
(Yes Phil but what's your point I know a guy running RTTY at 45 Baud 
with a tube converter and receiver/transmitter and he thinks this is 
state-of-the-art...a little humor helps the medicine taste better) 


I have to agree with phil. The industry I'm in is based on open 
standards and they are nessesary to allow the growth of this type of 
technology, and of course the growth of our company. And IBM is still 
one of the worlds largest suppliers of PC's! 


VVNV WV 


And 2X applies to hamradio or should... 


Developing a standard is a lot of work of course, but expecting to make 
the money back through selling a few licences at a high price may not be 
wise or in the companies best interests. 
There's probably very little in 
pactor II that we on HFSIG cannot duplicate without a licence. [STUFF DELETED] 
but we could make one just as good. 


VVVVV VV 


Very little indeed...I've worked with Mil-Std Modems on HF (I 

keep repeating myself) that run 2400 BPS on HF with little or 

no errors...expensive...yep initially at $56K, thne down to $15K, 

then down to $7K in 4 years. My bet is that the TAPR or Motorola 

or TI platforms and a 486 could do a darn good duplicating most of 
what they do...at least that's seems to be what I've been reading 

on this SIG for the past 2 years. 


If manufacturers, programers and ultimatly hams have a choice 
between an expensive propietry protocol in very limited use and a free 
open protocol thats just as good, then SCS may not be in a very good 
> position. 


Vv 


Its really more than just the protocol...its having hardware to 
make it "play". Remember the first TNCs? 8 1/2 X 11 boards and 
you used a VT-100 for the display and ran the beacon on and every 2 
minutes on 145.01. Then the TAPR TNC Kit...almost bought one when 
AEA came out with their first TNC. 


To sell it to the ham population in general you _must_ have 
available hardware for your software and it must be fairly easy 
to implement. 


The PTC II modem is very expensive, but then its a very complex bit of 
kit, and would make most PCs it would be used with look pretty lame. 
This box can 'pat its head and rub its belly at the same time while 
Alternativly a few ‘real' hams could develop an open standard, or adopt 
a MIL standard, and leave SCS in the lurch. 


VVVVV Vv 


Don't forget a hardware platform if needed.... 


Vv 


Lets develop an open standard and get better, faster and cheaper modems. 


For the last 2.5 years that's what I thought that this SIG was 
all about. 


Rob 


VVV WV 


| The MicroSoft operating system didn't get as bad as it is overnight, | 
| it has taken over 10 years of careful, calculated development. | 


| 

| | The greatest dangers to liberty 
| Walt DuBose - K5YFW | lurk in insidious encroachment 
| E-Mail k5yfw@www.kelly-afb.org | by men of zeal, well-meaning 

| Business Telephone: (210)925-6081 | but without understanding. 

| Home Telephone: (210)696-3196 | 

| | - Justice Louis D. Brandeis | 
| 


From LANIER.R.A-@smtpgty.bwi.wec.com Mon Jul 29 10:46:31 1996 
Received: from tron.bwi.wec.com (tron.bwi.wec.com [129.228.4.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAAQ3692 for <hfsig@tapr.org>; Mon, 29 Jul 1996 
10:46:29 -0500 (CDT) 
Received: from smtpgty.bwi.wec.com by tron. bwi.wec.com; 
(5.65/1.1.8.2/31May95-0229PM) 
id AA27564; Mon, 29 Jul 1996 11:44:20 -0400 

Received: from ccMail by smtpgty.bwi.wec.com 

(IMA Internet Exchange 2.0 Enterprise) id 1FCDDO080; Mon, 29 Jul 96 11:47:20 
-0400 
Mime-Version: 1.0 
Date: Mon, 29 Jul 1996 11:40:27 -0400 
Message-Id: <1FCDD080.1858@smtpgty .bwi.wec.com> 
From: LANIER.R.A-@smtpgty.bwi.wec.com (LANIER.R.A-) 
Subject: LM1868 Application Note 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


I am trying to locate a source for the components in the National 
Semiconductor Application Note for the LM1868, particularly the 
NR461EG, 1N60, and T3 (NS-107C made by Apollo Electronics). 


I am also trying to locate a source for varactor diodes, preferably 
ranging from 140pF to 5pF. The idea is to replace the tuning capactor 
with varactors. 


Can anyone help? 
Robert 


From forrerj@peak.org Tue Jul 30 21:54:32 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id VAAQ0454 for <hfsig@tapr.org>; Tue, 30 Jul 1996 
21:54:27 -0500 (CDT) 

Received: from p01.tO.monrotel.com (p01.tO.monrotel.com [198.68.25.34]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id TAAQ4021 for <hfsig@tapr.org>; Tue, 30 Jul 
1996 19:54:32 -0700 

Message-Id: <199607310254 . TAAQ4021@PEAK.ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 


Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 
Date: Tue, 30 Jul 1996 19:42:13 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer ) 
Subject: Re: [HFSIG:1322] ECC Book 


Hi Charles, 


I received my copy today and I think it is excellent. 

The theory is gently introduced and the code examples may come in very 
handy. Certainly is worth putting on my shelf along with Lin & Costello, and 
Michealson & Levesque's books. 


Thanks for pointing it out. 
--Johan, KC7WW 


(I ordered my copy from Powell's via the Internet (www.powells.com) ) 


>Has anybody seen this book and if so is it worth adding to the ‘library’ ?. 
> 
>Error Coding Cookbook: Practical C/C++ Routines and Recipes for 

Error Detection and Correction 

Disk Included 


C. Britton Rorabaugh 


Hard ISBN 0-07-911720-1 1996 
251p. 71 Illus. 7 3/8 x 9 1/4 
$55.00 


xx Description *x* 


> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> At last, the complexities of error coding are made simple If you 

> don't happen to be an abstract mathematician, it's all too easy to 
> get lost in the maze of error correction coding thats is a crucial 
> component of any signal processing or communications system. Now 

> this first-of-it-kind, non-theoretical guide clearly explains the 
> often complex error coding process. You'll find complete 

> step-by-step instructions on how to: Select the most appropriate 

> code for your particular application; Design the corresponding 

> coders and decoders; Implement many of the most well-known and 

> frequently used codes for error correction. Plus, you'll have 

> access to ready-to-use C and C++ programs for generating hundreds 
> of codes for error detection and correction on the accompanying 

> disk. The book's exceptionally clear descriptions of each code are 
> reinformed by an array of worked-out examples and a brief review 

> of only the necessary math where applicable. There has never been 
> a more illuminating or practical treatment of this always 


challenging and occasionally perplexing area. 

*xx Audience xx 
Electronics, electrical, communications, and computer engineers 
designing all types of communications and signal processing 
equipment. 

xx Contents ** 
Strategic Issues. Mathematical Tools for Coding. Block and Cyclic 


Codes. BCH and Reed-Solomon Codes. Encoders and Decoders. 
Convolutional Codes. Viterbi Decoding. Sequential Decoding. 


VV VV VV VV VV VV VV WV 


From karn@qualcomm.com Wed Jul 31 20:21:28 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id UAA21324 for <hfsig@tapr.org>; Wed, 31 Jul 1996 
20:21:26 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
SAA09782; Wed, 31 Jul 1996 18:20:51 -0700 (PDT) 

Date: Wed, 31 Jul 1996 18:20:51 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199608010120.SAA09782@servo.qualcomm. com> 

To: Robert.Glassey@nmp.nokia.com 

CC: hfsig@tapr.org 

In-reply-to: <H0000292021f32e2@MHS> (Robert.Glassey@nmp.nokia.com) 

Subject: Re: [HFSIG:1388] Re: Noise Blankers 


>these types of SS links. Error correction, which makes use of erasures 
>would effectivly 'smooth over' the pulses (as seem in the data stream). 


Error correction is an especially powerful technique with frequency 
hopped spread spectrum, as opposed to direct sequence. Both the 
frequency hopper and the narrowband user would benefit greatly from 
the ability to correct short bursts of errors, whether they occur from 
short bursts of interference or from natural channel degradations, 
such as static crashes and deep fades. 


It's instructive to compare the error rate curves for digital 
modulation on fading channels with those for nonfading channels. On 
the nonfading additive white gaussian noise (AWGN) channel, the error 
rate of most modulation schemes decreases either exponentially with 
SNR (for noncoherent schemes like FSK and DBPSK) or according to the 
error-integral ("Q") function (for coherent BPSK). 


But on a Rayleigh fading channel, both coherent and noncoherent 
schemes exhibit a error rate that decreases only xlinearlyx with 
increasing SNR. That is, if you want to decrease your bit error rate 
by a factor of 10, you need to increase your power by a factor of 
ten. The different schemes do differ in the precise amount of power 
required (e.g., ideal coherent BPSK is 3 dB better than DBPSK, which 


is 3 dB better than BFSK) but they are all exactly parallel over a 
very wide range of SNR. 


Some illustrative figures: for a BER of 1%, uncoded BPSK on a Rayleigh 
channel requires an Eb/NO of about 20 dB. To lower the BER to .1%, you 
need 30 dB. To achieve 10-6, you need an coax-melting Eb/NO of 60cB! 


If you're after a low error rate on a fading channel, the proper use 
of coding and interleaving can have a dramatic effect. While coding 
can get you perhaps 7 dB at best on an AWGN channel, on a Rayleigh 
fading channel it's not hard to achieve as much as 35 - 40 dB in power 
Savings compared to uncoded transmission. That's pretty impressive. 


Now these gains are admittedly somewhat separate from the issue of 
spread spectrum frequency hopping. But some bandwidth expansion just 
from the coding is inevitable, and this expansion is likely to be 
greater than on the AWGN channel. 


On the AWGN channel, you can get most of the achievable power gains 
with a bandwidth expansion of just 2-3x, e.g., by just adding rate 1/2 
or rate 1/3 convolutional coding to coherent PSK. The extreme coding 
gains achieved on Galileo with concatenated codes require about 4-5x 
additional bandwidth. 


But on the Rayleigh fading channel, both the achievable coding gains 
and the bandwidth expansion ratios are considerably greater. Not only 
are orthogonal signalling constellations with a fairly large number of 
dimensions necessary (e.g., M-ary FSK with large M), but the optimum 
FEC code rates for use with these schemes are lower than on the AWGN 
channel. For example, 16-ary FSK requires 4 times as much bandwidth as 
BFSK for the same data rate, and rate 1/8 coding is optimal for this 
value of M. That's a 32x bandwidth expansion, but it performs about 5 
dB better than a rate 1/2 code combined with BFSK (which only doubles 
the uncoded bandwidth) . 


So my main concern with the existing rules is that they keep us from 
using modulation and coding methods that conserve RF power. The result 
is a larger average amount of interference power to both narrowband 
and wideband users. Rules that would let us use power-efficient coding 
and modulation would be good even if they did not allow 
spread-spectrum per se. But these techniques run in a continuum, and 
I'm not sure how one would make a formal distinction in the 

rules. (E.g., a rate 1/100 convolutionally encoded BPSK signal is hard 
to distinguish from one that is direct sequence spread with a process 
gain of 1:100). 


Yes, it is possible to concoct worst cases where spread spectrum (or 
even a power-efficient wideband modulation scheme) could occasionally 
interfere with a nearby narrowband user. But there are many ways to 
mitigate this problem. I've already described how frequency hopping 
can be used instead of direct sequence to reduce the subjective effect 
of a given amount of average interference. It's also quite possible 
with frequency hopping to watch for narrowband interference and drop 


it from the hopping sequence, benefitting both users. (The most 
general approach to adapting to nonuniform interference is known as 
"water filling", used in some OFDM modems) . 


And it may not always be necessary to spread at all; ona lightly 
loaded band, you could simply turn off hopping once you've found what 
appears to be an empty channel. (This is equivalent to dropping every 
channel but one from the hopping list). 


But when the band gets loaded, and especially when the typical traffic 
consists of a lot of short, bursty transmissions, spread spectrum in 
general and frequency hopping in particular has the desirable effect 
of uniformly distributing the load over the band. The law of large 
numbers kicks in and the carrying capacity of the band increases 
thanks to the improved ability to dynamically share spectrum. 


And this is ultimately why we should encourage spread spectrum on all 
of our bands, especially the most crowded ones. 


Phil 


